Re: [PATCH v3] Replace hard-coded path with one from <paths.h>

From: Jakub Narebski <jnareb@gmail.com>
Date: Apr 15, 2010, 12:57 UTC
Message-ID: <201004151458.02156.jnareb@gmail.com>
In-Reply-To: <20100415124043.GH12365@arachsys.com>

On Thu, 15 April 2010, Chris Webb wrote:

Show 15 quoted lines

> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > All other such variables are described at the top of main Makefile,
> > for example:
> > 
> >   #
> >   # Define NO_LIBGEN_H if you don't have libgen.h.
> > 
> > I think that HAVE_PATHS_H should also have such one-line description.
> > By the way it the very first variable with HAVE_* rather than NEEDS_*
> > or NO_* name.
> 
> To be honest, I used the name suggested to me earlier in the thread without
> a great deal of checking to see how consistent it was with existing naming
> convention.

Actually HAVE_STH_H is the convention used in autoconf documentation. It is Git convention of NO_STH_H (well, the single example of NO_LIBGEN_H) that is non-standard... but this convention predates [optional] autoconf support in Git.

> 
> Blacklisting OSes with a NO_PATHS_H #define feels like a mistake, as unknown
> OSes will fail rather than assuming a safe (if slightly untidy) default. I
> got caught out assuming that Windows was sane in this regard, for instance.

Well, there is only one example of checking for _headers_, namely NO_LIBGEN_H, so it is not that you are against some majority.

In short: if there is no voice against HAVE_PATHS_H, lets have it this way.

Show 6 quoted lines

> 
> To me, NEEDS_PATH_H hints that a system with paths.h would break if it
> weren't included, rather than that this is an extra feature available on
> this OS. But if NEEDS_* is used elsewhere to enable optional extras on
> systems which support them, I agree we should change to NEEDS_PATH_H to be
> consistent.

Well, things like NEEDS_LIBGEN or NEEDS_SSL_WITH_CRYPTO are about a few systems that needs *extra* work. I don't think NEEDS_PATH_H is a good variable name.

-- 
Jakub Narebski
Poland