Changes to make Vim compile with X on OS X [with attachment]
Ben Schmidt
the logic of preprocessing in, say, vim.h doesn't solve the problem. Features
provided by the conflicting code are indeed needed together--you lose X
functionality or MacRoman encoding functionality depending what is disabled, and
there's no easy way to reconcile it by playing preprocessor games.]
Hi,
I recently had trouble compiling Vim on Mac OS X 10.4.9 with GTK2 GUI. As is
mentioned in the Vim source, the X headers and Mac headers clash horribly. This
means stuff has to be separated carefully into files that have X headers available
and those that have Mac headers available, and they weren't quite sorted out
right. The attached patch fixes it by moving code around:
- Moved from os_mac_conv.c to mac_gui.c and made static to that file:
- mac_utf16_to_enc
- mac_enc_to_utf16
- mac_enc_to_cfstring
- mac_utf16_to_utf8
- mac_utf8_to_utf16
- A chunk of code from option.c has also been moved to os_mac_conv.c
as 'mac_lang_init()'.
- And a preprocessor conditional in globals.h was changed so X headers
aren't expected when they aren't available.
I thought it was the best of a bad bunch of options for fixing the issues.
It now compiles for me, configured with
./configure --with-features=huge --enable-pythoninterp --enable-perlinterp
--enable-rubyinterp --enable-tclinterp --enable-cscope --enable-gui=gtk2
It would be good to have this or a similar fix in the official distribution.
Might this have an effect on MacVim, Bjorn, or vim-coco, Jiang (sorry if names
wrong...memory is hazy)? If so, perhaps you could suggest a better solution?
Cheers,
Ben.
Bram Moolenaar
Ben Schmidt wrote:
> [This copy contains the attachment. Also, I forgot to mention that
> simply changing the logic of preprocessing in, say, vim.h doesn't
> solve the problem. Features provided by the conflicting code are
> indeed needed together--you lose X functionality or MacRoman encoding
> functionality depending what is disabled, and there's no easy way to
> reconcile it by playing preprocessor games.]
>
> Hi,
>
> I recently had trouble compiling Vim on Mac OS X 10.4.9 with GTK2 GUI.
> As is mentioned in the Vim source, the X headers and Mac headers clash
> horribly. This means stuff has to be separated carefully into files
> that have X headers available and those that have Mac headers
> available, and they weren't quite sorted out right. The attached patch
> fixes it by moving code around:
>
> - Moved from os_mac_conv.c to mac_gui.c and made static to that file:
>
> - mac_utf16_to_enc
> - mac_enc_to_utf16
> - mac_enc_to_cfstring
> - mac_utf16_to_utf8
> - mac_utf8_to_utf16
I suppose you had to do this because MACOS_CONVERT is defined. Can't
you change vim.h not to define MACOS_CONVERT when building with GTK?
> - A chunk of code from option.c has also been moved to os_mac_conv.c
> as 'mac_lang_init()'.
>
> - And a preprocessor conditional in globals.h was changed so X headers
> aren't expected when they aren't available.
This isn't quite right, Win32 also has the balloon eval functionality.
And GTK too, so how can you omit this?
> I thought it was the best of a bad bunch of options for fixing the issues.
>
> It now compiles for me, configured with
>
> ./configure --with-features=huge --enable-pythoninterp --enable-perlinterp
> --enable-rubyinterp --enable-tclinterp --enable-cscope --enable-gui=gtk2
What GTK did you install?
> It would be good to have this or a similar fix in the official distribution.
Only when I'm sure it doesn't break anything.
> Might this have an effect on MacVim, Bjorn, or vim-coco, Jiang (sorry
> if names wrong...memory is hazy)? If so, perhaps you could suggest a
> better solution?
--
ARTHUR: Be quiet!
DENNIS: --but by a two-thirds majority in the case of more--
ARTHUR: Be quiet! I order you to be quiet!
WOMAN: Order, eh -- who does he think he is?
ARTHUR: I am your king!
The Quest for the Holy Grail (Monty Python)
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
björn
Unfortunately this patch will break MacVim compilation because of the
MacRoman encoding support won't get compiled (MacVim does not use
gui_mac.c, neither does vim-cocoa for that matter). Why is it not
possible to have the encoding functions in a separate source file?
That being said, I don't think it is a very serious problem for
MacVim...but it will require some work to reconcile it with your
patch. Either I'll have to move all those encoding functions into one
of the MacVim source files, or I'll have to rely on Cocoa for
conversion routines.
Now, I don't mind doing this too much, but at the moment I don't
understand the issues you are having, so I can't come up with any
better suggestions (but to me it seems unnecessary to have to poke
around in MacVim). Well, I did already say that things would be
better if the encoding functions were to reside in a source file that
I can include in MacVim (i.e. not gui_mac.c).
/Björn
Ben Schmidt
>>
>> - mac_utf16_to_enc
>> - mac_enc_to_utf16
>> - mac_enc_to_cfstring
>> - mac_utf16_to_utf8
>> - mac_utf8_to_utf16
>
> I suppose you had to do this because MACOS_CONVERT is defined. Can't
> you change vim.h not to define MACOS_CONVERT when building with GTK?
Yeah, you can, but
(1) that doesn't fix it, because os_mac_conv.pro contains prototypes with
Mac-specific types in them for those functions that weren't static in
os_mac_conv.c originally, and
(2) if you undefine that, you lose MacRoman support.
Maybe the better solution would be to assume the types won't change (they surely
never will!) and use some casts. Since the main problem is os_mac_conv.pro, if we
can just get the types out of the function signatures, we will be good:
UniChar <=> unsigned short (CFBase.h)
CFStringRef is a pointer type (as are all .*Ref, I believe) so could use void *.
>> - And a preprocessor conditional in globals.h was changed so X headers
>> aren't expected when they aren't available.
>
> This isn't quite right, Win32 also has the balloon eval functionality.
> And GTK too, so how can you omit this?
OK. I presume it's only a problem when we have Mac headers included, in which
case, we can use !defined(NO_X11_INCLUDES) instead of defined(FEAT_X11) and I
think that will cover it.
> What GTK did you install?
One that MacPorts installs. 2.0.10, I think. Anyone know how I check easily?
>> It would be good to have this or a similar fix in the official distribution.
>
> Only when I'm sure it doesn't break anything.
Yeah. I'm quite unsure myself which is why I wrote so much detail about it and
suggested something 'similar', by which I mean 'something that also works for me
but probably works better for everyone else too'!
I'll have a fiddle with it and if it works, send a revised patch in a few minutes.
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
Ben Schmidt
> MacRoman encoding support won't get compiled (MacVim does not use
> gui_mac.c, neither does vim-cocoa for that matter). Why is it not
> possible to have the encoding functions in a separate source file?
The problem is mostly Mac-specific prototypes in os_mac_conv.pro.
But if you look, none of the MacRoman functions have moved anyway, only Unicode
ones that it seems only things like clipboard support use in plain Vim. The
MacRoman stuff was left in os_mac_conv.c. Does MacVim use those same functions,
though? But as per my previous email, perhaps it is better to leave them where
they are and use casts. I'll see if it works that way and send a patch shortly if
it does. Then Bram can choose which he reckons is better. :-) It's probably a good
thing to have available for use by other Mac-related GUIs, even if MacVim doesn't
use them yet.
Cheers,
Ben Schmidt
by a different approach. It will definitely be better in some regards in light of
a few points that were raised, but I'm still not completely comfortable with
it--it does seem like a bit of a dirty hack. That said, it probably wouldn't cause
things to break--it just feels dirty/dangerous, though it is very safe. What do
you think now, guys? Is it looking good, or in need of further improvement?
Ben.
björn
It looks much better to me. Not that I am an expert on these matters,
but I don't see any (present or future) problems with replacing
UniChar* et al. the way you've done. For what it's worth I have no
objections to merging this patch.
/Björn