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

[Oleg Kolosov]

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

BTW, "standard" environment variable for include path is called just
"INCLUDE".

> Finally, regarding the Make page in the Single Unix Spec; that mentions
> tool names like CC, LD and options like CFLAGS.  It might be worthwhile
> trying to switch to those conventions, but for two things:
> 
> - It would probably break a lot more usages than the MANDIR and INCDIR
>   ...
> - I'm unsure how cross-compilation is usually handled.  There's only
>    one "CC" AFAIK, but CHICKEN needs (at most) three, in order to
>    distinguish between compiling this machine versus on the host
>    (when cross-compiling CHICKEN itself to another "host" platform)
>    the target machine (compiling with CHICKEN on the host machine to
>    another machine to run the final program on).

Some SDKs provide environment file which you need to source in current
shell to compile programs. This file usually exports CC, LD and others.
Few go as far as generating custom shell scripts intended to replace
cross compiler (for example mipsel-linux-gcc which passes sysroot and
some other specific options to every invocation of toolchain.

Actually, when working with cross Chicken, only one C compiler is needed
at the given build invocation. If environment is properly setup only
cross-compiler is needed when building for target platform. Building
Chicken itself is little more involved however.

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

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.

-- 
Regards, Oleg