[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: autoconf 2.52f and OS/2
From: |
Tim Van Holder |
Subject: |
Re: autoconf 2.52f and OS/2 |
Date: |
13 Feb 2002 14:09:16 +0100 |
On Wed, 2002-02-13 at 13:36, Akim Demaille wrote:
> >>>>> "Tim" == Tim Van Holder <address@hidden> writes:
>
> Tim> I know it's bad form to reply to your own posts, but here goes.
> >> That would be acceptable, as DJGPP's config.site sets CONFIG_SHELL
> >> to SHELL anyway. Unfortunately, config.site is loaded after this
> >> test.
>
> Tim> Akim, AFAICS AC_SITE_LOAD does not rely on any previous tests; it
> Tim> only needs the prefix variables. So could AC_SITE_LOAD be moved
> Tim> to an earlier point? That way, the pathsep test could use
> Tim> ${CONFIG_SHELL-/bin/sh}, allowing CONFIG_SHELL (or PATH_SEPARATOR
> Tim> for that matter) to be set in config.site. This would provide a
> Tim> functioning solution for both DJGPP and OS/2.
>
> I hate this part :( There are plenty of problems with AC_SITE_LOAD,
> and in particular, it seems obvious that it must be read before the
> handling of the command line args.
Hmmm - why? Before the actual _processing_ of command-line options,
maybe. But I don't see why the actual 'getopt' stuff can't happen
before _?AC_(INIT_)?SITE_LOAD. I haven't looked at the code though.
If absolutely necessary, we could always extract --prefix from the
command-line first, then load the site file (which only needs the
prefix anyway), and then do Everything Else(tm). Not the cleanest
solution, but not the dirtiest either, IMHO.
> Which implies that it cannot depend on $prefix.
That would be fine; there's always $CONFIG_SITE to specify a system-wide
one. Of course you lose the automatic loading of the 'correct' one for
the given prefix; e.g. you will probably have a different config.site
for the autoconf 2.13 you keep in /usr/crap and the autoconf-cvs you
keep in /usr/yippee.
> To me, this bit is a feature which is mis-designed. I'm in favor of
> moving AC_SITE_LOAD (BTW, ought to be _AC_SITE_LOAD, and maybe
> _AC_INIT_SITE_LOAD).
I wouldn't call is mis-designed as such; just a small chicken-and-egg
problem wrt the prefix.
> Tim, can you check that the doc allows this?
I'm not entirely sure if there's much documentation to begin with.
But I'll check.
> And if positive, to send a complete patch? (= code, doc, NEWS).
I'll try to send two patches: one that simply moves it a bit, and one
that splits the arg handling so the prefix is deduced separately in
order for the site load to happen as early as possible.