2 Oct
2012
2 Oct
'12
4:52 p.m.
On Tue, 2 Oct 2012, Cameron Kaiser wrote:
But I'd argue that's exactly what a configure script is *not* for. It's
supposed to look at the system you're compiling for and adapt itself
accordingly.
Now, if you want something that you can force presets of another system
for, that makes good sense and you can get such a package for Perl. But
I think that functionality is separate from an automatic configuration
system, because it's not automatic (you're manually feeding it your
settings).
I have to manually feed GNU autoconf so much stuff that it misdetects
that there might as well not be a ./configure at all. But I've never had
that issue with Perl or other "proper" configuration systems.
If the autoconf script is properly written, --cache-file is the main thing
you need. Many scripts don't properly handle or use config.cache for all
platform specific tests, even if they should.
Why would you expect a configure for that system to
cross-compile?
Because I am building an embedded device and a 8-core 2.5 GHz, 16 GB
RAM desktop computer has considerably more horse power then our 800
MHz, 256 MB RAM target? Because it is a PITA to set up the target to be
a compile host? (I am talking about $WORK here.)
I can't stand GNU autoconf / automake. But it handels this kind of
stuff pretty well, if the autoconf scripts are well written...