llvm dev - Sep 2004 - [LLVMdev] Auto-configuration of llvm/projects directory

Just a note about the change in auto-configuration of the llvm/projects
directory.

Previously, if we found any subdirectories of llvm/projects containing a 
configure script, it would be automatically configured by the llvm configure 
script. While this was handy, the necessary specification in the autoconf input 
file (configure.ac) used a deprecated feature of autoconf. This was replaced 
recently by having llvm/configure only automatically configure those 
directories it knows about. We can easily extend this list as new projects come 
along. This change means that our autoconf script is 100% error/warning free. 
This is a good thing.

The details:

The AC_CONFIG_SUBDIRS m4 macro is used in configure.ac to indicate a 
subdirectory that needs to have its configure script run after the main 
llvm/configure script is run. When specifying AC_CONFIG_SUBDIRS, you must 
specify the directory literally. If you use a variable instead of a liberal, 
you currently get a warning. The documentation says that this will, eventually, 
become an error as it is deprecated because using a variable cannot be 
successfully implemented on all platforms. That is, we can't write things
like:

if test -r projects/${proj}/configure ; then
   AC_CONFIG_SUBDIRS(${proj})
fi

Instead, autoconf requires us to write:

if test -r projects/llvm-test/configure ; then
   AC_CONFIG_SUBDIRS(projects/llvm-test)
fi

This change was requested by Misha who noted that "one of these things is
not
the same" and because I was uncomfortable with disregarding the autoconf 
warning messages about the misuse of AC_CONFIG_SUBDIRS.  We *could* put it back 
if its really necessary, but I would prefer that we just add known projects to 
the configure.ac script so we can use AC_CONFIG_SUBDIRS properly.

Reid.

On Thu, Sep 23, 2004 at 01:40:46PM -0700, Reid Spencer
wrote:
> If you use a variable instead of a liberal, you currently get a
> warning. 
What if one uses a conservative instead of a liberal? :)  *g, d, r*
> The documentation says that this will, eventually, become an error as
> it is deprecated because using a variable cannot be successfully
> implemented on all platforms. That is, we can't write things like:
> 
> if test -r projects/${proj}/configure ; then
>   AC_CONFIG_SUBDIRS(${proj})
> fi
> 
> Instead, autoconf requires us to write:
> 
> if test -r projects/llvm-test/configure ; then
>   AC_CONFIG_SUBDIRS(projects/llvm-test)
> fi
> 
> This change was requested by Misha who noted that "one of these things
> is not the same" and because I was uncomfortable with disregarding the
> autoconf warning messages about the misuse of AC_CONFIG_SUBDIRS. 
To be more to the point, what Misha noted was that every project was
named "llvm-xyz" with the exception of "Java".  He was not
talking about
the format of AC_CONFIG_SUBDIRS() .

-- 
Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu

On Thu, 2004-09-23 at 14:45, Misha Brukman wrote:
> On Thu, Sep 23, 2004 at 01:40:46PM -0700, Reid Spencer wrote:
> > If you use a variable instead of a liberal, you currently get a
> > warning. 
> 
> What if one uses a conservative instead of a liberal? :)  *g, d, r*
Yeah, I saw that typo after I sent the message and just knew someone
would comment on it. Figures it was you, Misha ;>

> To be more to the point, what Misha noted was that every project was
> named "llvm-xyz" with the exception of "Java".  He was
not talking about
> the format of AC_CONFIG_SUBDIRS() .
Okay, guess I was seeing something you weren't.

Reid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20040923/86cec0cd/attachment.sig>

On Sep 23, 2004, at 3:40 PM, Reid Spencer wrote:
>  The documentation says that [...] using a variable cannot be 
> successfully implemented on all platforms.
I find this somewhat hard to believe! At any rate, I'm sure we can find 
a reasonable workaround...

-Brian