From: Chris Webb <chris@arachsys.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
kusmabite@gmail.com, git@vger.kernel.org
Subject: Re: [PATCH v3] Replace hard-coded path with one from <paths.h>
Date: Thu, 15 Apr 2010 13:40:43 +0100 [thread overview]
Message-ID: <20100415124043.GH12365@arachsys.com> (raw)
In-Reply-To: <m3hbncgaxu.fsf@localhost.localdomain>
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.
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.
next prev parent reply other threads:[~2010-04-15 12:41 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-04 20:48 [PATCH] Replace hard-coded path with one configurable at make time Chris Webb
2010-04-04 21:38 ` Junio C Hamano
2010-04-04 22:28 ` Chris Webb
2010-04-06 16:35 ` Chris Webb
2010-04-06 16:36 ` [PATCH] Replace hard-coded path with one from <paths.h> Chris Webb
2010-04-07 10:57 ` Erik Faye-Lund
2010-04-08 10:58 ` Chris Webb
2010-04-08 11:26 ` Erik Faye-Lund
2010-04-08 11:57 ` [PATCH v2] " Chris Webb
2010-04-08 12:08 ` Erik Faye-Lund
2010-04-09 5:45 ` Chris Webb
2010-04-13 9:06 ` Chris Webb
2010-04-13 9:07 ` [PATCH v3] " Chris Webb
2010-04-13 20:01 ` Junio C Hamano
2010-04-14 7:22 ` Chris Webb
2010-04-15 12:27 ` Jakub Narebski
2010-04-15 19:15 ` Junio C Hamano
2010-04-15 12:25 ` Jakub Narebski
2010-04-15 12:40 ` Chris Webb [this message]
2010-04-15 12:57 ` Jakub Narebski
2010-04-15 13:01 ` Chris Webb
2010-04-15 13:21 ` [PATCH v4] " Chris Webb
2010-04-09 23:54 ` [PATCH] " Tait
2010-04-06 16:57 ` [PATCH] git-instaweb: pass through invoking user's path to gitweb CGI script Chris Webb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100415124043.GH12365@arachsys.com \
--to=chris@arachsys.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
--cc=kusmabite@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.