Re: AM_DEFAULT_SOURCE_EXT
RW == Ralf Wildenhues [EMAIL PROTECTED] writes: Hi Akim, hope I'm not going on your nerves yet .. ;-) Hi Ralf, Well, I'm the one who should plead guilty :( I apologize to be so not responsive. AM_DEFAULT_SOURCE_EXT = .cc Hum, actually I meant to use extensions without the dot :( OK, so I thought long enough about this issue to find an actual argument to support my case, and failed to find a good one for your case in the next couple of seconds after that. :-) Here it goes: the user could arguably want to use file names that do not contain a dot _at all_. Yes, definitely. And I do use that feature from time to time :) The only thing that is missing from portable make is that an inference rule SUFFIXES = -bla .c -bla.c: generate foo.c from foo-bla is not Posix-conforming (but in practice supported by several make implementations). I did not know it was not. Why not? I thought that SUFFICES suffixes to describe all the possible situations. My point about dropping the dot was really just to make it easier to describe a _tool_ connected to an extension, rather that a _rule_. But it's really a weak issue, maybe we can find an alternative syntax if there is really a need. Choose default source extension: AM_DEFAULT_SOURCE_EXT. * automake.in (handle_source_transform): Accept unconditional literal extension in AM_DEFAULT_SOURCE_EXT as override for the default source extension `.c'. If set, ignore the old default source rule for libtool libraries. * doc/automake.texi (Default _SOURCES): Document this. * NEWS: Update. * tests/specflg10.test: New test. * tests/Makefile.am: Update. Suggestion by Akim Demaille. This is really nice, thanks a lot!
Re: AM_DEFAULT_SOURCE_EXT
Hi Akim, * Akim Demaille wrote on Mon, Nov 17, 2008 at 09:47:31AM CET: RW == Ralf Wildenhues [EMAIL PROTECTED] writes: hope I'm not going on your nerves yet .. ;-) Well, I'm the one who should plead guilty :( I apologize to be so not responsive. Don't worry. The only thing that is missing from portable make is that an inference rule SUFFIXES = -bla .c -bla.c: generate foo.c from foo-bla is not Posix-conforming (but in practice supported by several make implementations). I did not know it was not. Why not? I thought that SUFFICES suffixes to describe all the possible situations. Well, SUFFIXES suffices for automake. It turns into .SUFFIXES which suffices for most make implementations out there. However, SUSv3 describes: | Inference rules are formatted as follows: | | target: | tabcommand | [tabcommand]... | line that does not begin with tab or # | | The application shall ensure that the target portion is a valid | target name (see Target Rules ) of the form .s2 or .s1.s2 (where .s1 and | .s2 are suffixes that have been given as prerequisites of the .SUFFIXES | special target and s1 and s2 do not contain any slashes or periods.) If | there is only one period in the target, it is a single-suffix inference | rule. Targets with two periods are double-suffix inference rules. | Inference rules can have only one target before the colon. so with anything other than exactly one leading dot in the suffix, we leave the Posix realm here. My point about dropping the dot was really just to make it easier to describe a _tool_ connected to an extension, rather that a _rule_. But it's really a weak issue, maybe we can find an alternative syntax if there is really a need. I think we can. Cheers, Ralf
Re: AM_DEFAULT_SOURCE_EXT
* Ralf Wildenhues wrote on Sun, Nov 02, 2008 at 10:58:08PM CET:
Choose default source extension: AM_DEFAULT_SOURCE_EXT.
* automake.in (handle_source_transform): Accept unconditional
literal extension in AM_DEFAULT_SOURCE_EXT as override for the
default source extension `.c'. If set, ignore the old default
source rule for libtool libraries.
* doc/automake.texi (Default _SOURCES): Document this.
* NEWS: Update.
* tests/specflg10.test: New test.
* tests/Makefile.am: Update.
Suggestion by Akim Demaille.
This caused a small regression, because I didn't rename variables
consistently. Fixed thusly.
Cheers,
Ralf
Fix regression introduced by AM_DEFAULT_SOURCE_EXT.
* automake.in (handle_source_transform): Use the right variable
when determining whether to apply the old rule for the libtool
library default source name.
Testsuite failure exposed by Bob Proulx' build daemon.
diff --git a/automake.in b/automake.in
index 9665e0b..9f50c8c 100755
--- a/automake.in
+++ b/automake.in
@@ -2085,7 +2085,7 @@ sub handle_source_transform (%)
if $default_source_ext =~ /[\t ]/;
(my $default_source = $unxformed) =~
s,(\.[^./\\]*)?$,$default_source_ext,;
if ($old_default_source ne $default_source
-!$default_source_ext
+!$ext_var
(rule $old_default_source
|| rule '$(srcdir)/' . $old_default_source
|| rule '${srcdir}/' . $old_default_source
Re: AM_DEFAULT_SOURCE_EXT
Hi Akim,
hope I'm not going on your nerves yet .. ;-)
* Ralf Wildenhues wrote on Tue, Oct 21, 2008 at 05:00:34AM CEST:
* Akim Demaille wrote on Mon, Oct 20, 2008 at 12:56:23AM CEST:
Le 18 oct. 08 à 03:02, Ralf Wildenhues a écrit :
* Akim Demaille wrote on Thu, Oct 16, 2008 at 04:11:22PM CEST:
AM_DEFAULT_SOURCE_EXT = .cc
Hum, actually I meant to use extensions without the dot :(
Erm, but you certainly didn't write it that way before! ;-)
Trying to find a distinctive meaning to extension and suffix… Of
course you should add a period before an extension to get a suffix
only when the extension is non-empty :)
This is a bike-shedding issue, right? Or is there a real reason?
FWIW, I find it easier to search for if the dot is part of the thing;
also, most uses inside automake include the dot (accept_extension et
al).
OK, so I thought long enough about this issue to find an actual argument
to support my case, and failed to find a good one for your case in the
next couple of seconds after that. :-)
Here it goes: the user could arguably want to use file names that do not
contain a dot _at all_. So, the setup could be
AM_DEFAULT_SOURCE_EXT = -bla
bin_PROGRAMS = foo
foo.c: foo-bla
generate $@ from foo-bla
CLEANFILES = foo.c
and automake would happily generate
bla_SOURCES = foo-bla
The only thing that is missing from portable make is that an inference
rule
SUFFIXES = -bla .c
-bla.c:
generate foo.c from foo-bla
is not Posix-conforming (but in practice supported by several make
implementations).
I am wondering whether DEFAULT_SOURCE_EXT would be preferable to
AM_DEFAULT_SOURCE_EXT?
I made it AM_ to avoid infringing on the user name space, but I'm fine
with just any name.
Good enough; I stuck with AM_DEFAULT_SOURCE_EXT for now.
Here's what I pushed.
Cheers,
Ralf
Choose default source extension: AM_DEFAULT_SOURCE_EXT.
* automake.in (handle_source_transform): Accept unconditional
literal extension in AM_DEFAULT_SOURCE_EXT as override for the
default source extension `.c'. If set, ignore the old default
source rule for libtool libraries.
* doc/automake.texi (Default _SOURCES): Document this.
* NEWS: Update.
* tests/specflg10.test: New test.
* tests/Makefile.am: Update.
Suggestion by Akim Demaille.
diff --git a/NEWS b/NEWS
index 98f6b53..5c7d295 100644
--- a/NEWS
+++ b/NEWS
@@ -36,6 +36,9 @@ New in 1.10a:
- Python 3.0 is supported now, Python releases prior to 2.0 are no
longer supported.
+ - The default source file extension (.c) can be overridden with
+AM_DEFAULT_SOURCE_EXT now.
+
* Miscellaneous changes:
- Automake development is done in a git repository on Savannah now, see
diff --git a/automake.in b/automake.in
index 0815773..4b54457 100755
--- a/automake.in
+++ b/automake.in
@@ -2058,10 +2058,16 @@ sub handle_source_transform (%)
if (scalar @keys == 0)
{
# The default source for libfoo.la is libfoo.c, but for
- # backward compatibility we first look at libfoo_la.c
+ # backward compatibility we first look at libfoo_la.c,
+ # if no default source suffix is given.
my $old_default_source = $one_file.c;
- (my $default_source = $unxformed) =~ s,(\.[^./\\]*)?$,.c,;
+ my $ext_var = var ('AM_DEFAULT_SOURCE_EXT');
+ my $default_source_ext = $ext_var ? variable_value ($ext_var) : '.c';
+ msg_var ('unsupported', $ext_var, $ext_var-name . can assume at most
one value)
+ if $default_source_ext =~ /[\t ]/;
+ (my $default_source = $unxformed) =~
s,(\.[^./\\]*)?$,$default_source_ext,;
if ($old_default_source ne $default_source
+!$default_source_ext
(rule $old_default_source
|| rule '$(srcdir)/' . $old_default_source
|| rule '${srcdir}/' . $old_default_source
diff --git a/doc/automake.texi b/doc/automake.texi
index cd2f920..86f1312 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -5605,6 +5605,7 @@ and we recommend avoiding it until you find it is
required.
@vindex SOURCES
@cindex @code{_SOURCES}, default
@cindex default @code{_SOURCES}
[EMAIL PROTECTED] AM_DEFAULT_SOURCE_EXT
@code{_SOURCES} variables are used to specify source files of programs
(@pxref{A Program}), libraries (@pxref{A Library}), and Libtool
@@ -5613,8 +5614,7 @@ libraries (@pxref{A Shared Library}).
When no such variable is specified for a target, Automake will define
one itself. The default is to compile a single C file whose base name
is the name of the target itself, with any extension replaced by
[EMAIL PROTECTED] (Defaulting to C is terrible but we are stuck with it for
-historical reasons.)
[EMAIL PROTECTED], which defaults to @file{.c}.
For example if you have the following somewhere in your
@file{Makefile.am} with no corresponding @code{libfoo_a_SOURCES}:
@@ -5631,7 +5631,7 @@ would be built from @file{sub_libc___a.c}, i.e.,
Re: AM_DEFAULT_SOURCE_EXT
* Akim Demaille wrote on Mon, Oct 20, 2008 at 12:56:23AM CEST: Le 18 oct. 08 à 03:02, Ralf Wildenhues a écrit : * Akim Demaille wrote on Thu, Oct 16, 2008 at 04:11:22PM CEST: I wish I could define AM_DEFAULT_SOURCE_EXT = .cc or whatever, so that I wouldn't have to define all the foo_SOURCES. I agree extension is better than suffix. (Even if Automake itself is inconsistent here and uses both.) Hum, actually I meant to use extensions without the dot :( Erm, but you certainly didn't write it that way before! ;-) Trying to find a distinctive meaning to extension and suffix… Of course you should add a period before an extension to get a suffix only when the extension is non-empty :) This is a bike-shedding issue, right? Or is there a real reason? FWIW, I find it easier to search for if the dot is part of the thing; also, most uses inside automake include the dot (accept_extension et al). I am wondering whether DEFAULT_SOURCE_EXT would be preferable to AM_DEFAULT_SOURCE_EXT? I made it AM_ to avoid infringing on the user name space, but I'm fine with just any name. Yeah, not infringing is probably good. Trying to find a general rule would be even better. Hmm, Variables using an `AM_' prefix are either automake-rule-specific sister variables of the respective user API variables without that prefix (typically, those end in `FLAGS'); or they change some mode of operation of `automake' runtime. The second part is not consistent. * AM_INSTALLCHECK_STD_OPTIONS_EXEMPT is purely 'make installcheck' run time issue, * AM_COLOR_TESTS is purely a 'make check' run time issue, * OTOH, AUTOMAKE_OPTIONS is important at 'automake' run time, but doesn't have the prefix. ACLOCAL_AMFLAGS is also not so consistent. I wonder now whether we should rename AM_COLOR_TESTS to COLOR_TESTS. OTOH, as graphics program I might want to use the latter for something entirely different... +(my $default_source = $unxformed) =~ s,(\.[^./\\]*)?$, $default_source_ext,; So Automake cannot leave with using $(AM_DEFAULT_SOURCE_EXT) as a symbolic value? No. It really needs to perform the substitution statically? Yes. Otherwise all the rest comes for free (conditionals, possibility to change the extension on the command line (not that I think of a particular use here, but...)). Believe me, it won't come for free. The *SOURCES parser is quite involved just to deal with conditionals; it outright forbids symbolics. +AM_DEFAULT_SOURCE_EXT = .cpp Just my 0.02 French Francs (yeah, I know, today the currency is €, but in the context of criticism/critique, the French currency definitely seems more appropriate): .cpp reminds me too me about CPP, I prefer .cc/.cxx :) And you're quite entitled to never use .cpp in your sources. However, it is the only extension for C++ source code that is accepted without further command line option by every C++ compiler we know of. (MS cl needs a switch to come right before the name otherwise.) So that is not an issue of personal preference. Cheers, Ralf
Re: AM_DEFAULT_SOURCE_EXT (was: Parallel tests execution [0/4])
Le 18 oct. 08 à 03:02, Ralf Wildenhues a écrit : * Akim Demaille wrote on Thu, Oct 16, 2008 at 04:11:22PM CEST: I wish I could define AM_DEFAULT_SOURCE_EXT = .cc or whatever, so that I wouldn't have to define all the foo_SOURCES. I agree extension is better than suffix. (Even if Automake itself is inconsistent here and uses both.) Hum, actually I meant to use extensions without the dot :( Trying to find a distinctive meaning to extension and suffix… Of course you should add a period before an extension to get a suffix only when the extension is non-empty :) I also agree that using *_EXT is better than *_EXTENSION (too long, also there is precedent in EXEEXT and OBJEXT). I am wondering whether DEFAULT_SOURCE_EXT would be preferable to AM_DEFAULT_SOURCE_EXT? I made it AM_ to avoid infringing on the user name space, but I'm fine with just any name. WDYT about the simplistic patch below? (yes, allowing conditional definition would be the next step.) Never thought about that :) Yuck, yuck. Cheers, and good idea BTW! Bah, it's easy to have good ideas when you have the need. What's harder is what you did: to come up with a solution. And documentation. And tests. And NEWS :) + (my $default_source = $unxformed) =~ s,(\.[^./\\]*)?$, $default_source_ext,; So Automake cannot leave with using $(AM_DEFAULT_SOURCE_EXT) as a symbolic value? It really needs to perform the substitution statically? Otherwise all the rest comes for free (conditionals, possibility to change the extension on the command line (not that I think of a particular use here, but...)). @example check_PROGRAMS = test1 test2 test3 +AM_DEFAULT_SOURCE_EXT = .cpp @end example Just my 0.02 French Francs (yeah, I know, today the currency is €, but in the context of criticism/critique, the French currency definitely seems more appropriate): .cpp reminds me too me about CPP, I prefer .cc/.cxx :)
