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

2014-06-13 Thread 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

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

2014-06-13 Thread Felix Winkelmann
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

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

2014-06-13 Thread Felix Winkelmann
And, at Felix: what was the reason you didn't use CC but your own C_COMPILER variable? Just to avoid getting in conflict with user settings, and perhaps also to make sure that these are chicken-specific. I agree that it probably makes more sense to use the standard variable names. felix

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

2014-06-13 Thread Christian Kellermann
Felix Winkelmann felix.winkelm...@bevuta.com writes: 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). Please note that

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

2014-06-13 Thread Peter Bex
On Fri, Jun 13, 2014 at 10:14:51AM +0200, Felix Winkelmann wrote: 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