patchBuild on Debian GNU/Hurd

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@smarden.org>

---
 Makefile |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

hoi :)

On Fri, Sep 15, 2006 at 12:58:46PM +0000, Gerrit Pape wrote:

I guess this arbitrary limit will upset all the Hurd enthusiasts... ;-)

Gerrit Pape <pape@smarden.org> writes:

Two questions come to mind. (1) Does GNU stand for GNU/Hurd and nobody else? (2) Does everybody else have PATH_MAX?

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.

Would including git-compat-util.h in builtin.h break somebody?

-- >8 -- Define fallback PATH_MAX on systems that do not define one in <limits.h>

Notably GNU/Hurd, as reported by Gerrit Pape.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

On Fri, Sep 15, 2006 at 10:35:57PM -0700, Junio C Hamano wrote:

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.

It's been so before it seems, I'm not sure why it changed. http://www.debian.org/ports/hurd/hurd-devel-debian says one cannot expect PATH_MAX to be defined on a POSIX system, so defining it conditionally IMHO is the right thing.

 git$ PAGER=cat git log -p 579d1fb..8e76483
 commit 8e76483ce0ce256b01345abc4ca97b1f94aed354
 Author: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
 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@ramsay1.demon.co.uk>
     Signed-off-by: Junio C Hamano <junkio@cox.net>
 
 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[];
  

HTH, Gerrit.

On Tues Sept 19, 2006 at 18:04, Gerrit Pape wrote:

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.

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

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

On Thu, 21 Sep 2006, Ramsay Jones wrote:

Well, considering that we _can_ test defines, why not just do it automatically.

In other words, instead of this patch:

Just make the code read

	#include <limits.h>

	/*
	 * Insane systems don't have a fixed PATH_MAX, it's POSIX
	 * compliant but not worth worrying about, so if we didn't
	 * get PATH_MAX from <limits.h>, just make up our own
	 */
	#ifndef PATH_MAX
	# define PATH_MAX 4096
	#endif

and after that we can just ignore the issue forever more.

The thing is, it's not like we even really _care_ what PATH_MAX is all that deeply. We just want to get some random value that is reasonable.

		Linus

On Thurs Sept 21 at 18:54, Linus Torvalds wrote:

Yes, that would certainly be a solution. (Of course, setting the value in the Makefile would still be a better solution ;-) However, ...

... given the above, a better solution is: don't use PATH_MAX. Simply #define a new symbol in a suitable git header file and globally replace uses of PATH_MAX with the new symbol. Job done.

All the best,

Ramsay