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. 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. 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. > Why not > > +#ifdef HAVE_PATHS_H > +#include <paths.h> > +#endif > +#ifndef _PATH_DEFPATH > +#define _PATH_DEFPATH "/usr/local/bin:/usr/bin:/bin" > +#endif > > This way you are covered if some other header provides _PATH_DEFPATH. Yes, makes sense, although I think _PATH_DEFPATH is very unlikely to be provided outside of <paths.h>. Best wishes, Chris. -- 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