On Thu, 15 April 2010, Chris Webb wrote: > Jakub Narebski <jnareb@xxxxxxxxx> 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. > > 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 -- 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