Bernard Dautrevaux wrote:
>
> Sure enough; I constantly forget this, probably because I *never* run
> configure manually but through a script in the build tree (and BTW type
> "./configure" instead of "make reconfigure" as my scripts usually
> automatically call aclocal/autoconf/automake)
Well, it's not that I like to run the configure directly, the point is
the Makefile.in generated by `automake`. It has some, well, dependencies,
that will trigger `config.status` or `config.status --recheck` which will
in turn run the original `configure XXX --no-create`. Now just replace
the XXX with the arguments originally given to `configure`. But if you had
some interesting shellvariables on the initial `configure`, well, they are
lost in here, so that `configure` may fail.
>
> > As for cross-compiling, I'd ask if there is a pre-include option, e.g.
> > --include=<pathtoshellscript>, where the script could hold the various
> > cache-variables to be preset, or even start to preset $CC. This option
> > would also go into the `make reconfigure`, so all you need is
> > a (global) script that has all the cache-variables at hand for the
> > target-platforms
>
> In fact that's exactly what my wrapper script does: depending on the
> platform I'm compiling for, preset various variables (CC, CFLAGS,
> ac_cv_bigendian, etc.) before calling configure (note that I also use a
> similar script to call make too).
>
> Of course such a site-wide host-dependent set of default settings would be
> nice and should simplify all my scripts.
>
That's what I'm talking about. The current `configure` does currently
two things to preset shellvariables: it first looks for a "site-wide"
shellscript named by $CONFIG_SITE (defaults to $prefix/(share|etc)/config.site)
and loads that one, and right thereafter the config.cache is loaded.
Now guess what - there is no `configure`-option to set $CONFIG_SITE,
and furthermore, the default is not dependent on the --target option.
Well, I call this a flaw in the config.site handling, and somewhere
around that piece of the configure-script, some enhancement would
be easy - and it would surely solve the problems of many cross-compiling
setups. Two propositions, to be discussable on the mailing-list:
a) add an option "--config-file=<file>" that sets $CONFIG_SITE. This equals
the option "--config-cache=<file>" that sets $cache_file. May be some
other variable $config_file would be needed, so $CONFIG_SITE is not
assigned to. Should get the same advertising in the help-screen as
--config-cache does.
b) enhance the default-guess for the place of config.site, especially if
the user gave an explicit "--target" option. The $target-default is NONE,
so we have decent fallback case. Any suggestions where to look
if $target != NONE ?
if only (b) is used, it may result for the same problemspace we have now,
where the rural autoconf-user does not even know about "config.site". So
I strongly suggest to have atleast (a) and putting it on the help-screen.
The choosing of the filepath for (b) is tricky - a wise decision is
needful. Just add the --target argument as another subdirectory just before
config.site in the current defaultpath? Look also for --build? prepend it
as as subdirectory too? What about --host?
Opinions please...
-- Guido ICQ: 49289035 GSM:+49-175-9723679
