[prev in list] [next in list] [prev in thread] [next in thread] 

List:       vim-mac
Subject:    Re: $VIM and $PATH on Mac OS X
From:       Dany St-Amant <dany.stamant () sympatico ! ca>
Date:       2001-11-13 4:41:00
[Download RAW message or body]


Le Dimanche 11 novembre 2001, à 12:30 , Benji Fisher a écrit :

> On Friday, November 9, 2001, at 10:18  PM, Dany St-Amant wrote:
>
>> Applications under MacOS X inherit the environment of their invoker,
>> so if you change PATH of VIM in Terminal.app and then do
>> "open Vim.app", you'll use those new PATH and VIM.
>
>      This works, but I want to compile, package, and distribute a 
> version that can be placed in the Applications/
>  directory.  Opening from Terminal.app is not the way to go.
>
>> Vim on MacOS X is defaulting $VIM to the executable path. To use
>> a hardcoded path you'll have to undefine USE_EXE_PATH
>> and maybe change the wrap the use of exe_name in os_mac.c
>> with a #ifdef USE_EXE_PATH.
>
>      Can you be more explicit?  Where is USE_EXE_PATH defined?  I could 
> not find it, even using grep.  Since I define OS_X_UNIX, isn't os_mac.c 
> skipped?  I really think that hard-coding $VIM is the best alternative, 
> if Vim.app is going to go in the Applications/ directory (I mean 
> folder).

Doh!. I should have type USE_EXE_NAME and gui_mac.c. The check #ifdef is
already there. If Vim is place inside a folder inside the Application 
folder, the
current auto-detect should, but won't be nice. In misc1.c, function 
'expand_env'
we could try to avoid the removal of VIm.app by not calling (unless 
build is
present)

		pend = remove_tail_with_ext(p, pend, (char_u *)".app");

Or we could add back the Vim.app (should use the original name removed) 
in the
function vim_version_dir. This could allow us to put the $VIMRUNTIME 
inside
VIm.app (which I think is the way recommended by Apple, one big fat 
application
folder)

> [...]
>      I am beginning to think that ProjectBuilder ignores the 
> makefiles.  Is that right?  Either way, what is the recommended way to 
> enable/disable features?  I guess I can either edit feature.h or define 
> macros (-DSTUFF) in ProjectBuilder.  Is there a way to compile with 
> +perl?

The os_mac.pbproj is by itself a makefile. Since there's a empty 
auto/config.h supplied
in the distribution it should not be hard to try to get Project Builder 
to use it as a template.
But it will require a lot of #ifdef in os_mac.h and gui_mac.h (I didn't 
got ride of os_mac.h for -DMACOS_X.. Another problem (as shown by 
os_macosx.c) is that I haven't yet found
a way to conditionally compile a file without the use of a wrapper.

Dany, currently looking at:
-providing a Console/Carbon combo (works somehow but strangely)
-how easy to get a Cocoa version (seems easier that I originally though, 
but no time)
-how to get ./configure to go Carbon (I'm having headaches)
-fixing small issues
-can't remember what else

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic