[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] Small improvement in Make's handling of va
Re: [Chicken-hackers] [PATCH] Small improvement in Make's handling of variables, and a question about other common variables
Fri, 13 Jun 2014 08:38:59 +0200
On Fri, Jun 13, 2014 at 01:53:51AM +0400, Oleg Kolosov wrote:
> On 06/12/14 23:56, Peter Bex wrote:
> > Anyway, long story short, I think it's a good idea to stick closer
> > to commonly found conventions and to allow all the configurable
> > directory prefixes to be copied from the environment.
> You can look for hints in commonly used build systems implementations.
> I'm not sure how autotools handle this, but CMake have quite elaborate
> rules, see:
Thanks, but I think this is for locating existing files rather than
installing programs into locations. This could be useful too if we want
to supply better defaults in other places.
> BTW, "standard" environment variable for include path is called just
I think you've mixed up two variables: I think here INCLUDE is the
include _path_ as searched by the C compiler when building, whereas
INCLUDEDIR is the directory into which to copy include files when
installing. If you look further down that page, under GNUInstallDirs,
it says this:
INCLUDEDIR - C header files (include)
This is what I've seen most as it's the GNU convention, which autotools
use. NetBSD's pkgsrc sets a few environment directories in bsd.pkg.mk,
and they call it INCSDIR:
Some libraries from NetBSD's base system use INCDIR, like CHICKEN (but
there it means the base include dir, unlike in CHICKEN). I think we
should support whatever is the most common, and I think that's
> Actually, when working with cross Chicken, only one C compiler is needed
> at the given build invocation.
No, you need *two* C compilers when working with a cross-CHICKEN, because
you can install extensions on the host. This is necessary for syntax
extensions like "matchable", for example: those run inside the compiler,
on the host system, when compiling a program for the target system.
Compare chicken-install's -host and -target options.
> > So, all in all, it may be safer to avoid re-using the common CFLAGS etc.
> > My patch doesn't touch the tool variables because I think this warrants
> > more up-front discussion.
> FYI, CMake propagates these environment variables too.
> Currently I'm handling these like this:
> When compiling Chicken itself, do not use environment, compute
> compilation flags based on Makefiles but allow user to override.
> When compiling Chicken generated C files, add these computed flags to
> user supplied from environment or through configure options.
Thanks for sharing your experience with CMake. I agree it's probably
fine to use these variables as defaults, but still allow overrides for
> It might not be the best way but works so far. I'm no sure in particular
> about -fno-strict-aliasing and -fwrapv. Maybe allowing user to override
> these will break something subtly.
Those two are a constant source of frustration :( I think we can best
ignore them for now, as they're causing trouble either way: even providing
them by default in the platform Makefiles can be problematic (see Haiku).
Re: [Chicken-hackers] [PATCH] Small improvement in Make's handling of variables, and a question about other common variables, Felix Winkelmann, 2014/06/13
Re: [Chicken-hackers] [PATCH] Small improvement in Make's handling of variables, and a question about other common variables, Peter Bex, 2014/06/13
Re: [Chicken-hackers] [PATCH] Small improvement in Make's handling of variables, and a question about other common variables, Aleksej Saushev, 2014/06/17
Re: [Chicken-hackers] [PATCH] Small improvement in Make's handling of variables, and a question about other common variables, Christian Kellermann, 2014/06/19