Tom Tromey wrote:
>
> >>>>> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
>
> Lars> I believe everything should be in order (I believe I filled out
> Lars> for Automake and maybe even Libtool when I did it for Autoconf).
>
> Yeah, I found the info.
>
> Lars> Anyways, the patch should be reworked to use a &canonicalize()
> Lars> sub as Akim suggested
>
> I agree.
>
> Lars> What I'm really wondering about is whether you accept the
> Lars> semantics of the patch; allowing AC_SUBSTS in for instance
> Lars> library names...
>
> I understand the need to be able to rename programs and libraries.
> I've had other requests for that.
>
> So the question is whether this is how we want to do it.
>
> What are other ways? One other way would be to support the name as an
> attribute of the object:
>
> bin_PROGRAMS = foo
>
> foo_SOURCES = ...
> foo_NAME = @what-foo-really-is@
>
> Is this more confusing? Or less?
>
> Over time I've come to dislike arbitrary @FOO@ substitutions, because
> they limit the amount of knowledge automake has about what is going
> on. In this case it might not be so bad.
>
> Tom
The thing is, that since every AC_SUBST'd variable is transformed into a
make variable, you can already specify all sorts of derived stuff using
make variables in Makefile.am's with the CVS automake. For example:
in the configure.in
AC_SUBST(arch)
AC_SUBST(nonthreaded)
AC_SUBST(nonthreaded_sources)
and in the Makefile.am
foo_SOURCES = foo.c fee_$(arch).c
lib_LTLIBRARIES = libfoo_$(nonthreaded).la
libfoo___nonthreaded__la_SOURCES = foo.c $(nonthreaded_sources)
EXT_DIST = $(threaded_sources)
So I'm not sure that doing autoconf substitution really adds anything.
I took a stab at updating the documentation to explain this concept and
its limitation but I'm having trouble figuring out the meaning of the
texinfo tags.
Michael
--
------------------------------------------------------------------
Michael Bletzinger Software Developer, Alliance Computational
[EMAIL PROTECTED] Environment & Security
217 265 5137 NCSA
