[PATCH] Build on Debian GNU/Hurd

[PATCH] Build on Debian GNU/Hurd

[Gerrit Pape]

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(-)

diff --git a/Makefile b/Makefile
index 7b3114f..6e36eff 100644
--- a/Makefile
+++ b/Makefile
@@ -383,6 +383,11 @@ ifeq ($(uname_S),NetBSD)
 	ALL_CFLAGS += -I/usr/pkg/include
 	ALL_LDFLAGS += -L/usr/pkg/lib -Wl,-rpath,/usr/pkg/lib
 endif
+ifeq ($(uname_S),GNU)
+       # GNU stands for GNU/Hurd
+       NO_STRLCPY = YesPlease
+       ALL_CFLAGS += -DPATH_MAX=4096
+endif
 ifeq ($(uname_S),AIX)
 	NO_STRCASESTR=YesPlease
 	NO_STRLCPY = YesPlease
-- 
1.4.2.1

Re: [PATCH] Build on Debian GNU/Hurd

[Martin Waitz]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

hoi :)

On Fri, Sep 15, 2006 at 12:58:46PM +0000, Gerrit Pape wrote:
> +ifeq ($(uname_S),GNU)
> +       # GNU stands for GNU/Hurd
> +       NO_STRLCPY = YesPlease
> +       ALL_CFLAGS += -DPATH_MAX=4096
> +endif

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

-- 
Martin Waitz

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Build on Debian GNU/Hurd

[Junio C Hamano]

Gerrit Pape <pape@smarden.org> 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@smarden.org>
>
> +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?

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>
---
diff --git a/git-compat-util.h b/git-compat-util.h
index 552b8ec..0272d04 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -26,6 +26,13 @@ #include <netinet/in.h>
 #include <sys/types.h>
 #include <dirent.h>
 
+/* On most systems <limits.h> would have given us this, but
+ * not on some systems (e.g. GNU/Hurd).
+ */
+#ifndef PATH_MAX
+#define PATH_MAX 4096
+#endif
+
 #ifdef __GNUC__
 #define NORETURN __attribute__((__noreturn__))
 #else
diff --git a/builtin.h b/builtin.h
index 34ed7b9..1d41f83 100644
--- a/builtin.h
+++ b/builtin.h
@@ -1,8 +1,7 @@
 #ifndef BUILTIN_H
 #define BUILTIN_H
 
-#include <stdio.h>
-#include <limits.h>
+#include "git-compat-util.h"
 
 extern const char git_version_string[];
 extern const char git_usage_string[];

Re: [PATCH] Build on Debian GNU/Hurd

[Gerrit Pape]

On Fri, Sep 15, 2006 at 10:35:57PM -0700, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> 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@smarden.org>
> >
> > +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.
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.

RE: [PATCH] Build on Debian GNU/Hurd

[Ramsay Jones]

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@smarden.org> 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@smarden.org>
> > >
> > > +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@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[];
>   

RE: [PATCH] Build on Debian GNU/Hurd

[Linus Torvalds]

On Thu, 21 Sep 2006, Ramsay Jones wrote:
> 
> 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.

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

In other words, instead of this patch:

> >  -
> >  -#ifndef PATH_MAX
> >  -# define PATH_MAX 4096
> >  -#endif
> >  +#include <limits.h>

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

RE: [PATCH] Build on Debian GNU/Hurd

[Ramsay Jones]

On Thurs Sept 21 at 18:54, Linus Torvalds wrote:
> On Thu, 21 Sep 2006, Ramsay Jones wrote:
> >
> > 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.
>
> Well, considering that we _can_ test defines, why not just do it
> automatically.
>
> In other words, instead of this patch:
>
> > >  -
> > >  -#ifndef PATH_MAX
> > >  -# define PATH_MAX 4096
> > >  -#endif
> > >  +#include <limits.h>
>
> 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.

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

>
> 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
>

... 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