First, sorry for posting this on the wrong list. I realised what I'd
done just after I pushed send.
On 19/01/11 2:51 PM, Bram Moolenaar wrote:
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.
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..
Cheers,
Ben.
diff -r 239e56f593ee src/xxd/Makefile
--- a/src/xxd/Makefile Tue Jan 18 22:18:14 2011 +1100
+++ b/src/xxd/Makefile Wed Jan 19 15:29:41 2011 +1100
@@ -1,7 +1,10 @@
# The most simplistic Makefile
-xxd: xxd.c
- $(CC) $(CFLAGS) $(LDFLAGS) -DUNIX -o xxd xxd.c
+xxd: xxd.o
+ $(CC) $(LDFLAGS) -o xxd xxd.o
+
+xxd.o: xxd.c
+ $(CC) $(CFLAGS) -DUNIX -c -o xxd.o xxd.c
clean:
rm -f xxd xxd.o
--
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
