Re: [Chicken-hackers] [PATCH] Small improvement in Make's handling of variables, and a question about other common variables

[Peter Bex]

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:
> http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:find_path

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
> "INCLUDE".

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:
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/mk/bsd.pkg.mk
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
INCLUDEDIR.

> 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
the cross-compiler.

> 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).

Cheers,
Peter
-- 
http://www.more-magic.net