Re: [revised patch 1/1] support AC_SUBST'able automake rules
"Lars J. Aas" wrote: > > On Fri, Feb 09, 2001 at 10:48:38AM -0600, Michael Bletzinger wrote: > : 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) > > Ah, I missed this "hack" when I started trying. I don't consider it to > be "supported", though, since you need to transform the characters... > > : So I'm not sure that doing autoconf substitution really adds anything. > > If nothing else, it will de-obfuscate such hacks as the one above :) Well one person's hack is another person's cool trick :-) On the minus side using an autoconf substitution limits the characters you can use for target names because the name has to translate to a make variable. That's why the character transformation is in automake. On the plus side using autoconf will resolve all of the targets after configure is run while using make variables will postpone the resolution until the make install step. I don't have a problem with your patch. I just want to collect enough information so that these things can be written up in the docs. Michael > > Lars J > -- > Innovation is one percent inspiration and ninetynine percent perspiration, > and in my case; twice that... -- Norville Barnes, `The Hudsucker Proxy' -- -- Michael Bletzinger Software Developer, Alliance Computational [EMAIL PROTECTED] Environment & Security 217 265 5137NCSA
Re: [revised patch 1/1] support AC_SUBST'able automake rules
On Fri, Feb 09, 2001 at 10:48:38AM -0600, Michael Bletzinger wrote: : 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) Ah, I missed this "hack" when I started trying. I don't consider it to be "supported", though, since you need to transform the characters... : So I'm not sure that doing autoconf substitution really adds anything. If nothing else, it will de-obfuscate such hacks as the one above :) Lars J -- Innovation is one percent inspiration and ninetynine percent perspiration, and in my case; twice that... -- Norville Barnes, `The Hudsucker Proxy'
Re: [revised patch 1/1] support AC_SUBST'able automake rules
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 5137NCSA
Re: [revised patch 1/1] support AC_SUBST'able automake rules
> "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
Re: [revised patch 1/1] support AC_SUBST'able automake rules
On Thu, Feb 08, 2001 at 12:05:28AM -0700, Tom Tromey wrote: : > "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: : Lars> Anyways, are the people that count looking into this patch? I'd : Lars> prefer it if it was applied or rejected as soon as possible : Lars> instead of waiting in the dark... : : What, and break the long automake tradition of getting email about : your patch 8 months later? I know it's tradition, but I'm not that keen on keeping traditions for the sake of tradition :)... : I assume you don't have automake paperwork filed. Do you? I believe everything should be in order (I believe I filled out for Automake and maybe even Libtool when I did it for Autoconf). Anyways, the patch should be reworked to use a &canonicalize() sub as Akim suggested, and it's probably less than 10 lines that will change. What I'm really wondering about is whether you accept the semantics of the patch; allowing AC_SUBSTS in for instance library names... Lars J -- Innovation is one percent inspiration and ninetynine percent perspiration, and in my case; twice that... -- Norville Barnes, `The Hudsucker Proxy'
Re: [revised patch 1/1] support AC_SUBST'able automake rules
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes: Lars> Anyways, are the people that count looking into this patch? I'd Lars> prefer it if it was applied or rejected as soon as possible Lars> instead of waiting in the dark... What, and break the long automake tradition of getting email about your patch 8 months later? I assume you don't have automake paperwork filed. Do you? If not tell me and I will send you the form you have to fill out. Usually I'm less enthused about reading a patch unless I know the paperwork is in process. Sometimes it turns out that paperwork can't be filled out due to restrictive employers. Tom
Re: [revised patch 1/1] support AC_SUBST'able automake rules
"Lars J. Aas" <[EMAIL PROTECTED]> writes: > Anyways, are the people that count looking into this patch? I will, when I have time :( Sorry for the delays...
Re: [revised patch 1/1] support AC_SUBST'able automake rules
On Wed, Jan 31, 2001 at 05:02:06PM +0100, Lars J. Aas wrote: : I've revised the patch to include the latest changes from CVS Autoconf, : which made the complate patch somewhat simpler than before. I even corrected complete My fingers are slippy today. Anyways, are the people that count looking into this patch? I'd prefer it if it was applied or rejected as soon as possible instead of waiting in the dark... Lars J -- Innovation is one percent inspiration and ninetynine percent perspiration, and in my case; twice that... -- Norville Barnes, `The Hudsucker Proxy'
Re: [revised patch 1/1] support AC_SUBST'able automake rules
I've revised the patch to include the latest changes from CVS Autoconf,
which made the complate patch somewhat simpler than before. I even corrected
the changelog date :)
2001-01-31 Lars J. Aas <[EMAIL PROTECTED]>
* automake.in ($CANONICALS): New variable containing the character
ranges allowed in canonical names, using it where appropriate.
($MACRO_PATTERN, $CANONICALS): Allow '@'s in automake macro names.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.843
diff -u -r1.843 automake.in
--- automake.in 2001/01/31 14:36:21 1.843
+++ automake.in 2001/01/31 15:55:57
@@ -46,7 +46,7 @@
# Only recognize leading spaces, not leading tabs. If we recognize
# leading tabs here then we need to make the reader smarter, because
# otherwise it will think rules like `foo=bar; \' are errors.
-$MACRO_PATTERN = "^ *([A-Za-z0-9_]+)[ \t]*([:+]?)=[ \t]*(.*)\$";
+$MACRO_PATTERN = "^ *([A-Za-z0-9_\@]+)[ \t]*([:+]?)=[ \t]*(.*)\$";
$BOGUS_MACRO_PATTERN = "^ *([^ \t]*)[ \t]*([:+]?)=[ \t]*(.*)\$";
$GNITS_VERSION_PATTERN = "[0-9]+\\.[0-9]+([a-z]|\\.[0-9]+)?";
$IF_PATTERN = "^if[ \t]+\([A-Za-z][A-Za-z0-9_]*\)[ \t]*\(#.*\)?\$";
@@ -55,6 +55,7 @@
$PATH_PATTERN='(\\w|[/.-])+';
# This will pass through anything not of the prescribed form.
$INCLUDE_PATTERN = "^include[
\t]+((\\\$\\\(top_srcdir\\\)/${PATH_PATTERN})|(\\\$\\\(srcdir\\\)/${PATH_PATTERN})|([^/\\\$]${PATH_PATTERN}))[
\t]*(#.*)?\$";
+$CANONICALS = "A-Za-z0-9_\@";
# Some regular expressions. One reason to put them here is that it
# makes indentation work better in Emacs.
@@ -1717,7 +1718,7 @@
local ($name, @suffixes) = @_;
local ($xname, $xt);
-($xname = $name) =~ tr/A-Za-z0-9_/_/c;
+($xname = $name) =~ s/[^$CANONICALS]/_/og;
if ($xname ne $name)
{
local ($xt);
@@ -1849,7 +1850,7 @@
foreach $one_file (@proglist)
{
# Canonicalize names.
- ($xname = $one_file) =~ tr/A-Za-z0-9_/_/c;
+ ($xname = $one_file) =~ s/[^$CANONICALS]/_/og;
if (&variable_defined ($xname . '_LDADD'))
{
@@ -1953,7 +1954,7 @@
foreach $onelib (@liblist)
{
# Canonicalize names.
- ($xlib = $onelib) =~ tr/A-Za-z0-9_/_/c;
+ ($xlib = $onelib) =~ s/[^$CANONICALS]/_/og;
if (&variable_defined ($xlib . '_LIBADD'))
{
&check_libobjs_sources ($xlib, $xlib . '_LIBADD');
@@ -2114,7 +2115,7 @@
foreach $onelib (@liblist)
{
# Canonicalize names.
- ($xlib = $onelib) =~ tr/A-Za-z0-9_/_/c;
+ ($xlib = $onelib) =~ s/[^$CANONICALS]/_/og;
if (&variable_defined ($xlib . '_LIBADD'))
{
&check_libobjs_sources ($xlib, $xlib . '_LIBADD');
@@ -2318,7 +2319,7 @@
push (@texi_deps, '$(srcdir)/' . $vtexi) if $vtexi;
# Canonicalize name first.
- ($canonical = $infobase) =~ tr/A-Za-z0-9_/_/c;
+ ($canonical = $infobase) =~ s/[^$CANONICALS]/_/og;
if (&variable_defined ($canonical . "_TEXINFOS"))
{
push (@texi_deps, '$(' . $canonical . '_TEXINFOS)');
