On Tue, Apr 27, 2010 at 06:08:58PM +0200, Tor Arntsen wrote: > On Tue, Apr 27, 2010 at 15:57, Gary V. Vaughan <git@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > enum style is inconsistent already, with some enums declared on one > > line, some over 3 lines with the enum values all on the middle line, > > sometimes with 1 enum value per line... and independently of that the > > trailing comma is sometimes present and other times absent, often > > mixing with/without trailing comma styles in a single file, and > > sometimes in consecutive enum declarations. > > > > Clearly, omitting the comma is the more portable style, and this patch > > changes all enum declarations to use the portable omitted dangling > > comma style consistently. > > The patch is against master. Are we supposed to make patches against > master or maint? (I thought I saw the latter somewhere. I'm pretty > new in here though..) No, the patch is against the latest 7.1.1 stable release (not yet shown on the website last time I checked, however): http://www.kernel.org/pub/software/scm/git/git-1.7.1.tar.bz2 > I can confirm that master doesn't compile on AIX 5.1 with the IBM > VisualAge compiler V5 (V5.0.2) without the patch above, and it does > compile with the patch: > > Tested-by: Tor Arntsen <tor@xxxxxxxxxxx> Thanks for testing. > but with the following caveats: > > 1: With the patch, it'll build with configure (and only configure), > run like so: > > ./configure --enable-pthreads=-lpthread CFLAGS=-Dinline='' The pthread issue is taken care of by pthread.patch (later in this series), which also adds defaults to Makefile. The inline issue is taken care of by no-inline.patch (the last patch in this series), for configure based builds at least. > In other words, this system would also need an AIX version of the > 'no-inline' patch you did for HP-UX. This should be as simple as adding the following to the appropriate AIX defaults section of Makefile: ifeq ($(shell expr "$(uname_V).$(uname_R)" : '5\.1'),3) INLINE='' endif But, honestly (with the obvious exception of the few architectures that don't have access to a posix shell and command line tools) I really don't see the value of burning perfectly good development time by trying to maintain 2 separate build systems... irrespective of what its detractors would like you to believe, configure is specifically designed to discover things like this empirically *on the actual build machine* - no matter what particular combination of libc, compiler, operating system and/or patchlevels a build host happens to be running on the day of the build: trying to maintain an accurate database of what quirks are present in all combinations of the above is a far more difficult, likely impossible, undertaking. > And without the --enable-pthreads=-lpthread above it'll try to link > with -pthread, which won't work for this system. Did you apply the whole series of patches? If so, then it is a bug in my pthread.patch if --enable-pthreads=-lpthreads is necessary. This configure line builds successfully on all the architectures I have access to (note, pthread support is probed automatically by configure): {SHELL} ./configure CC="${CC:-gcc}" CFLAGS="${CFLAGS:--O2}" \ CPPFLAGS="-I${SB_VAR_CURL_INC} \ ${SB_VAR_LIBEXPAT+-I${SB_VAR_LIBEXPAT_INC}} \ ${SB_VAR_LIBZ+-I${SB_VAR_LIBZ_INC}} ${CPPFLAGS+${CPPFLAGS}}" \ LDFLAGS="${SB_VAR_GCC_RT+-L${SB_VAR_GCC_RT_LIB}} \ ${SB_VAR_LIBEXPAT+-L${SB_VAR_LIBEXPAT_LIB}} \ ${SB_VAR_LIBZ+-L${SB_VAR_LIBZ_LIB}} \ -L${SB_VAR_CURL_LIB} \ ${SB_VAR_GCC_RT+${CC_LD_RT}${SB_VAR_GCC_RT_LIB}} \ ${SB_VAR_LIBEXPAT+${CC_LD_RT}${SB_VAR_LIBEXPAT_LIB}} \ ${SB_VAR_LIBZ+${CC_LD_RT}${SB_VAR_LIBZ_LIB}} \ ${CC_LD_RT}${SB_VAR_CURL_LIB} ${LDFLAGS+${LDFLAGS}}" \ ${SB_VAR_LIBEXPAT+--with-expat} \ ${SB_VAR_LIBICONV+--with-iconv=${SB_VAR_LIBICONV}} \ --without-openssl --with-curl ${ARGS+"${ARGS}"} \ --prefix=${SB_INSTALL_PREFIX} where ${SB_VAR_...LIB} and ${SB_VAR_...INC} hold the paths to the relevant libdir and includedir directories for the named packages, ${CC_LD_RT} is "-Wl,--rpath," or equivalent, and SB_VAR_GCC_RT_LIB refers to the GCC runtime and is predicated on whether gcc is used (i.e. on Linux). > The const-expr patch is also useful for AIX-5.1 / XlC V5.0.2. It > does build without, but with warnings. IRIX6.5 however fails to compile altogether without const-expr.patch. > 2: The compiler cannot build on AIX 5.1 without the following > additional patch (against master. maint has similar problems but > files have been moved): I maintained a similar patch for our packaging of older git releases too, but noticed that it wasn't necessary on our machines anymore... perhaps recent compiler patches on our hosts have relaxed the requirement for non-C++ comment syntax? However, I do confirm that this is a problem I have encountered in the past. > From a8989213b4c8baa53c14c1f227b916910265c517 Mon Sep 17 00:00:00 2001 > From: Tor Arntsen <tor@xxxxxxxxxxx> > Date: Tue, 27 Apr 2010 16:05:12 +0000 > Subject: [PATCH 2/2] C99 comments changed to old-style C comments > > Signed-off-by: Tor Arntsen <tor@xxxxxxxxxxx> > --- > builtin/blame.c | 2 +- > builtin/for-each-ref.c | 4 ++-- > remote.c | 2 +- > 3 files changed, 4 insertions(+), 4 deletions(-) Cheers, -- Gary V. Vaughan (gary@xxxxxxxxxxxxxxxxxx) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html