Ben Schmidt wrote: > >> - netbeans.pro uses the type BalloonEval which is not included if no X11 > >> headers are; I worked around this by adding typedef void to the .c > >> files that #define NO_X11_INCLUDES. It's a nasty hack, but I haven't > >> fiddled with the Vim source code for so long I don't have any idea > >> what the 'right way' would be, so I figured I might as well just do a > >> hack and someone else would know the proper way. > > > > It's probably OK, so long as BalloonEval isn't actually used. > > Yeah. It works; it's just ugly. The benefit of typedef void is that if > something attempts to use it, it will give a compiler error. Another > alternative could be to forward-declare it as a struct, I suppose. > > >> - FEAT_GUI is not defined if NO_X11_INCLUDES is defined (because doing > >> so would pull in a lot of stuff that needs the X headers), so the > >> check of FEAT_GUI in os_macosx.c is useless; I worked around it by > >> unconditionally defining a different constant. > > > > FEAT_GUI_ELSEWHERE sounds strange. Otherwise it looks like the best > > workaround. > > Yeah. There must be a better name. I just can't think of one. I'm sure > you can think of something you'd be happy to have in the Vim source. :-) > > >> It'd be great if you could put similar workarounds in the source, Bram, > >> so it can compile out of the box. > >> > >> Also, I am seeing src/xxd/xxd.dSYM created during a build which isn't > >> ignored by hg. It'd be good to add this to .hgignore or something. > > > > I don't see any .dSYM files ignored, don't you see more of these? > > No. I think I've figured out why it is. When you run Apple's GCC with > -g, producing an executable from a source file, it makes the .dSYM > (bundle/directory) with it. If you go explicitly via an object file, you > don't get it. So maybe doing something like below is a better solution.
Thanks. > Another thing that's causing a bit of trouble is src/auto/config.mk. A > 'stub file' is in version control, but it gets regenerated during the > build, so always shows up as a modified file. Then it has to be avoided > when commiting changes locally or updating to different points in > history, etc.. Could we perhaps remove it from version control? > Actually, probably better is to rename it, and include a command in > whatever script is used to prepare distributions to copy it into place > for inclusion in those. Then it wouldn't get in the way and make it > difficult to prepare patches, etc.. Problem is that when typing "make" that file is needed. It must exist, even if it's only an empty file. Thus "hg pull" must obtain it. Since preparing patches is not a common operation, it's better to put the work there. -- hundred-and-one symptoms of being an internet addict: 117. You are more comfortable typing in html. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
