autoconf-patches
[Top][All Lists]
Advanced

[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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]