On Tues Sept 19, 2006 at 18:04, Gerrit Pape wrote: > On Fri, Sep 15, 2006 at 10:35:57PM -0700, Junio C Hamano wrote: > > Gerrit Pape <pape@xxxxxxxxxxx> writes: > > > Patch from Cyril Brulebois to make the build process detect > and support the > > > Debian GNU/Hurd architecture, see > > > http://bugs.debian.org/379841 > > > > > > Signed-off-by: Gerrit Pape <pape@xxxxxxxxxxx> > > > > > > +ifeq ($(uname_S),GNU) > > > + # GNU stands for GNU/Hurd > > > + NO_STRLCPY = YesPlease > > > + ALL_CFLAGS += -DPATH_MAX=4096 > > > +endif > > > > Two questions come to mind. (1) Does GNU stand for GNU/Hurd and > > nobody else? (2) Does everybody else have PATH_MAX? > > I'm not that familiar with the Hurd, but (1) seems to be so according > to http://www.gnu.org/software/hurd/hurd.html; it looks like either GNU > or GNU/Hurd is used. (2) For IRIX64 PATH_MAX also is defined explicitly > > git$ grep -B7 -A3 PATH_MAX Makefile > ifeq ($(uname_S),IRIX64) > NO_IPV6=YesPlease > NO_SETENV=YesPlease > NO_STRCASESTR=YesPlease > NO_STRLCPY = YesPlease > NO_SOCKADDR_STORAGE=YesPlease > SHELL_PATH=/usr/gnu/bin/bash > ALL_CFLAGS += -DPATH_MAX=1024 > # for now, build 32-bit version > ALL_LDFLAGS += -L/usr/lib32 > endif > > that's where I got it from. > > > Adding NO_STRLCPY I do not have much problems with, but > > something like the attached may be cleaner to deal with PATH_MAX; > > of course now there is an issue of what the appropriate value > > for that symbol should be. > > It's been so before it seems, I'm not sure why it changed. Because without the change (below), git would not compile for me ;-) Indeed it would not compile for any system that: 1) defines PATH_MAX in limits.h AND 2) conditionally defines PATH_MAX to a different value. (Actually, it does not have to be a different value, just a different token sequence, including the presence/absence of whitespace/comments) Note that other systems use a different "PATH_MAX value", (a value of 1024 is common), and in particular, earlier version of linux use a value of 4095. > http://www.debian.org/ports/hurd/hurd-devel-debian says one cannot > expect PATH_MAX to be defined on a POSIX system, Correct. Although PATH_MAX is a POSIX symbol, it is not required to be defined; it *may* be defined in limits.h and, if so, must have a value of at least 256. The symbol _PC_PATH_MAX *may* also be defined and, if so, may be used in a call to pathconf() to *maybe* determine a "PATH_MAX value" at runtime; it can return a value, indicate no limit, or an "indeterminate" limit. ... so defining it > conditionally IMHO is the right thing. IMHO, setting the value in the Makefile, for systems that don't define PATH_MAX, is a much better solution. In fact, that is what I thought was already being done. All the best, Ramsay > > git$ PAGER=cat git log -p 579d1fb..8e76483 > commit 8e76483ce0ce256b01345abc4ca97b1f94aed354 > Author: Ramsay Allan Jones <ramsay@xxxxxxxxxxxxxxxxxxx> > Date: Sun Jul 30 17:00:40 2006 +0100 > > Fix header breakage due to redefining PATH_MAX. > > The header builtin.h was, incorrectly, redefining PATH_MAX which > causes a header order dependency in builtin-write-tree.c. The fix > is to simply include <limits.h> directly to obtain the correct > definition of PATH_MAX. > > Signed-off-by: Ramsay Allan Jones <ramsay@xxxxxxxxxxxxxxxxxxx> > Signed-off-by: Junio C Hamano <junkio@xxxxxxx> > > diff --git a/builtin.h b/builtin.h > index 1c8637a..88c4d84 100644 > --- a/builtin.h > +++ b/builtin.h > @@ -2,10 +2,7 @@ #ifndef BUILTIN_H > #define BUILTIN_H > > #include <stdio.h> > - > -#ifndef PATH_MAX > -# define PATH_MAX 4096 > -#endif > +#include <limits.h> > > extern const char git_version_string[]; > - 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