On Thu, Jan 30, 2014 at 06:49:50PM +1100, Jack Kelly wrote: > Yann Dirson <ydir...@free.fr> writes: > > It is not uncommon for software packages to build tools to be executed > > at build time, to generate data files or more input files to compile. > > > > ... > > > > For the second point, it would seem a good idea at some point to > > support a "native_" prefix, so setting eg. "native_PROGRAMS" will > > trigger the use of BUILD_* tools. > > I am no longer particularly familiar with automake internals, but I do > think some sort of "this is for the build machine" is a very good idea. > > At the risk of descending into bikeshedding, I'm not sure that native_ > is the best option, because just about everything that is foo_PROGRAMS > describes something built from native code. build_ isn't great either > (despite the symmetry with AC_CANONICAL_BUILD &c.) because most of what > automake does involves building programs.
You're right, much too right :) The idea of forcing onto the world to name "build" our host platforms, and "host" our target platforms, just so that we can use "host" and "target" correctly when we're cross-building a cross toolchain has always looked unbelievable to me (as if we couldn't just use a special term, say finaltarget, foobar or whatever, just for that special case), and I still regularly have to sit back and spend some brain cycles to get things right. I miss the possibility of calling the host compiler HOST_CC as it should be. </rant> Wondering if we could find a way to fix that, without breaking compatility in unacceptable ways... Something like "./configure --sanity=yesplease --host= -target=" would easily restore sanity for the user, while keeping "./configure --build= --host=" working for all existing scripts. The price is already high, and having a similar flag to set in configure.ac is going to drive macro writers mad :)
