Re: CVS commit: src/sys/dev
On Tue, 26 Jul 2011, David Young wrote: I used this semantic patch: [...] - #define bar 0x10 + #define bar PCI_BAR(0) White space on + lines is taken literally, whereas white space on context lines and - lines is matched loosely. This means that spatch will convert from any amount of white space before and after the identifier bar, to exactly one space. If you would prefer to retain the original white space, then you can avoid using white space in + lines, like this: #define bar -0x10 +PCI_BAR(0) At least, that works in normal code; I don't know whether it works in #define lines. --apb (Alan Barrett)
Re: CVS commit: src/sys/arch/alpha/alpha
Looking how many atoi() copies we have in tree, does it make sense to add the following at the end of libkern.h Please don't use it for #ifdef _STANDALONE ones. libc's strtoll() is larger than dumb atoi()s. ...if strtoll isn't already pulled in for other reasons. On i386, only netboot variants pull strtoul(), so I don't think we can assume strtoll() is already pulled in most standalone ones. --- Izumi Tsutsui
Re: CVS commit: src/sys/dev
On Wed, Jul 27, 2011 at 10:04:19AM +0200, Alan Barrett wrote: If you would prefer to retain the original white space, then you can avoid using white space in + lines, like this: #define bar -0x10 +PCI_BAR(0) At least, that works in normal code; I don't know whether it works in #define lines. I *would* prefer to retain the original whitespace. Thank you so much for the advice. I will try this out, later, and let you know if it works on #define lines or not. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 344-0444 x24
Re: CVS commit: src/external/mit/xorg
mrg@ wrote: Module Name: src Committed By: mrg Date: Sat Jul 23 23:42:02 UTC 2011 Modified Files: src/external/mit/xorg/bin/bdftopcf: Makefile src/external/mit/xorg/tools/fc-cache: Makefile src/external/mit/xorg/tools/mkfontscale: Makefile Log Message: link against bz2 where necessary. This reminds me PR bin/44138. (some OS doesn't have bzip.h by default) Is bzip2 support necessary even for tools? hmm, good point. i'll have a look at this but if someone wants to beat me to it that would be great. tools/fc-cache fails on CentOS 5: --- : # compile fc-cache/ftbzip2.lo cc -O -DFONTCONFIG_PATH='/usr/local/src/obj.i386/destdir.i386/etc/X11/fonts' \ -DFC_DEFAULT_FONTS='/usr/X11R7/lib/X11/fonts/Type1' \ -DFC_CACHEDIR='/usr/local/src/obj.i386/destdir.i386/var/cache/fontconfig' \ -DHAVE_FT_BITMAP_SIZE_Y_PPEM -DHAVE_FT_GET_BDF_PROPERTY \ -DHAVE_FT_GET_NEXT_CHAR -DHAVE_FT_GET_PS_FONT_INFO \ -DHAVE_FT_GET_X11_FONT_FORMAT -DHAVE_FT_HAS_PS_GLYPH_NAMES \ -DHAVE_EXPAT -DXFREE86_FT2 -DHAVE_INTTYPES_H -DFT2_BUILD_LIBRARY \ -DXML_BYTE_ORDER=0 -DHAVE_MEMMOVE=1 -DHAVE_STDINT_H -DHAVE_RANDOM \ -DDARWIN_NO_CARBON -I/usr/local/xsrc/external/mit/fontconfig/dist \ -I/usr/local/xsrc/external/mit/freetype/dist \ -I/usr/local/xsrc/external/mit/freetype/dist/include \ -I/usr/local/xsrc/external/mit/expat/dist//lib \ -I/usr/local/xsrc/external/mit/fontconfig/dist/../include \ -I/usr/local/src/obj.i386/destdir.i386/usr/X11R7/include -I. -c -o \ ftbzip2.lo.o/usr/local/xsrc/external/mit/freetype/dist/src/bzip2/ftbzip2.c \ /usr/local/xsrc/external/mit/freetype/dist/src/bzip2/ftbzip2.c:51:19: \ error: bzlib.h: No such file or directory : --- I'll check if bzip2 support in tools is really necessary. --- Izumi Tsutsui
