Re: problem with conditionals and \ separator in SOURCES
Tom Tromey wrote: > > > "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes: > > >> Am I doing something wrong? > >> Notice that this problem only takes place with cygwin > > Tim> Might be an EOL issue; sed is notorious for not recognizing a trailing \ > Tim> in a DOS text file (it sees \ + CR + NL). > Tim> Try converting the file to Unix text. > > Tim> Note: this is just a hunch. > > Sounds like a good hunch to me. > > Automake 1.4 didn't try to deal with DOS-style line endings correctly. You're right: line endings are to blame... the funny thing is that I got the sources from a Linux CVS server, and the uncorrect line endings seem to have been added during the dowloading... (actually I used WinCVS, so this is quite likely). > > For that matter I don't know whether the cvs automake does. It does > set `binmode' on its output, but it might not handle \r\n in its input > too well. > > Lorenzo, can you check this? I didn't understand this last point: what should I check? What is cvs automake? thanks Lorenzo -- +-+ | Lorenzo Bettini ICQ# lbetto, 16080134 | | PhD student in Computer Science| | Florence - Italy (Linux User # 158233) | | Home Page: http://w3.newnet.it/bettini | | http://infostud.dsi.unifi.it/~bettini | | Mail : [EMAIL PROTECTED]| | http://www.mokabyte.it Java on line journal | | http://music.dsi.unifi.it XKlaim language | | http://w3.newnet.it/bettini/purple Cover Band | | http://www.gnu.org/software/java2html & cpp2html | +-+
Re: Patch: make dist in subdirs before handling the current directory
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: Robert> * distdir.am: Recurse into subdirs before handling files Robert> in the current directory. Robert> This patch reverses the order of subdir processing with Robert> current directory files for the make dist target. I don't think this is the right thing to do. Reversing the order solves the problem in one particular case, but it might introduce new problems we don't know about. That becomes more true if/when we have the dist target depend on `all'. Instead I think the right thing to do is for automake to notice when it is dealing with a dist-able object in a subdir and then at dist time make the subdir and fill it with those files. This will let things work even when the subdir doesn't have a Makefile of its own. We already have most of the code in place to do this; it shouldn't be very hard to finish. Tom
Re: testcase for make dist with subdir SOURCES
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: Robert> The attached test csae demonstrates the problem. I don't think Robert> I'll have time to step upto the coding plate, but I figure a Robert> the test might make things easier ... :] Thanks, I'm checking in a variant of this test. Tom
dependency generation problems
I'm attempting to use automakes provisions for automatic dependecy generation, and I'm running into problems. When I try to run make, after configuring, I get this error: Making all in af make[2]: Entering directory `/home/sam/projects/abi-auto/build/src/af' GNUmakefile:261: .deps/libAf.la.Plo: No such file or directory make[2]: *** No rule to make target `.deps/libAf.la.Plo'. Stop. make[2]: Leaving directory `/home/sam/projects/abi-auto/build/src/af' There are, of course, no files in that .deps directory, since they haven't been generated yet. So, since this is supposed to generate the .Plo files, why is it complaining that they don't exist? The only potential cause that I can think of is that the actual source files are two further directory levels below the one in the error, and I know automake doesn't deal so well with deep directory trees. However, make in a lower level directory has a similar result. [sam@samth build]$ automake --version automake (GNU automake) 1.4a I hope this is enough info for someone to figure out what is going wrong. Thanks sam th --- [EMAIL PROTECTED] --- http://www.abisource.com/~sam/ OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key DeCSS: http://samth.dyndns.org/decss PGP signature
Re: AM_MAKE_INCLUDE [patch]
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> So, below is a patch to address this issue by applying make -s. Ralf> If this doesn't work out, the entire check probably needs to be Ralf> reworked. Thanks, I checked this in. I wrote up the test as part of the patch and verified it. I also wrote a ChangeLog entry. Tom
Re: 85-lang-new-hash.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> The patch is really a proposal: it relies on a modified version Akim> of Perl 5.6's Class::Struct. The modification are minimal, and Akim> just ensure that it works with 5.005: I've already weighed in on most of this... Akim> I still have no idea whether the license makes it possible for Akim> us to distribute and install this file as, say, AutomakeStruct. Akim> But before investigating, I would like to have opinions. This Akim> is a significant simplification of Automake, and given that I Akim> plan to use even more objects in the future, it would Akim> drastically simplify a lot of code to use it. I agree this is the route we want to go. For the language code, I would have gone this way originally but I still maintained the idea of supporting Perl 4 at that time. Akim> +my $lang = new Language (%option); I still think we should have a separate class per language. This seems cleanest by far. It might seem heavy now, but we'll be kicking ourselves in a year if we don't do it. Tom
Re: 82-lang-finish.patch
> "Akim" == akim <[EMAIL PROTECTED]> writes: >> I have a mild dislike for this. >> If `finish' were a method then we could simply inherit it. Akim> I do share your dislike for the structure, but please, note that Akim> we are defining methods per _object_. Cleaner would mean one Akim> *class* per language, which seems overkill to me. Really? Why? To me it seems natural. Tom
Re: Scripts...
> "Alex" == Alex Turner <[EMAIL PROTECTED]> writes: >> For automake I use AC_SUBST and have @...@ substitutions in >> automake.in. Alex> Cool - actualy I forgot to ask if this is a sane way to do it Alex> for C. I would much prefer it generated a header file with it Alex> in somewhere. A header is a bit cleaner but there are some tricky issues regarding expansion of the prefix. For instance $(datadir) expands to the text `$(prefix)/share', which isn't directly usable from C code. There are various tricks to get around this. One is a -D option in the Makefile, since the expansion will be handled by make. Another trick is a macro which will expand a path for you. I think you can get this from the autoconf macro archive. Maybe it is in the cvs autoconf already (if not, it should be, since this comes up quite a bit). Alex> P.S. Tom Tromey: Thanks for spending the time to write a book on Alex> automake etc... it's very very usefull. You're welcome. Thank the other authors too, since they did more work than me. Tom
Re: Scripts...
On 10 Apr 2001, Tom Tromey wrote: > > "Alex" == Alex Turner <[EMAIL PROTECTED]> writes: > > Alex> What is the best way to have a script/program where $pkgdatadir > Alex> is located? > > I assume you mean how to find pkgdatadir in a program? > > Alex> For C, it's easy enough just to do > Alex> CCFLAGS=-DPKGDATADIR="\""$(pkgdatadir)"\"" but what about things > Alex> like perl scripts that have to pull option files and such. Is > Alex> there a standard way to tackle this? > > For automake I use AC_SUBST and have @...@ substitutions in > automake.in. > > Tom > Cool - actualy I forgot to ask if this is a sane way to do it for C. I would much prefer it generated a header file with it in somewhere. Alex P.S. Tom Tromey: Thanks for spending the time to write a book on automake etc... it's very very usefull.
Re: 82-lang-finish.patch
On Tue, Apr 10, 2001 at 03:20:15PM -0600, Tom Tromey wrote: > > "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: > > I have a mild dislike for this. > If `finish' were a method then we could simply inherit it. I do share your dislike for the structure, but please, note that we are defining methods per _object_. Cleaner would mean one *class* per language, which seems overkill to me.
Re: 82-lang-finish.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in: (Language): Add attribute `_finish'. Akim> (&finish): New. Akim> (Automake): Adjust. Akim> (&lang_header_finish, &lang_yaccxx_finish, &lang_lexxx_finish) Akim> (&lang_asm_finish): Remove. I'm not so sure about this patch. These are precisely the kinds of things I would like to turn into methods. What you're doing is sort of like a method, but uglier to my eyes. Why not make real packages? Akim> - 'extensions' => ['s', 'S'])); Akim> + 'extensions' => ['s', 'S'], Akim> + # We need the C code for assembly. Akim> + '_finish' => \&lang_c_finish)); I have a mild dislike for this. If `finish' were a method then we could simply inherit it. Tom
Re: overriding tested automake & aclocal in test suite
Tom Tromey wrote: > > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: > > Derek> Is there some reason the automake test suite doesn't allow the > Derek> user to override its AUTOMAKE & ACLOCAL variables? > > Thanks for the patch. I wrote a ChangeLog entry for you. Could you > write it next time? Yep. Sorry about that. Busy day. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- This is the fourth? - Thomas Jefferson's last words (he died on the 4th of July)
Re: 78-lang-autodep.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> Actually I'm realizing it does make a significant difference! Akim> With my patch you get: Akim> add_depend2 (cxx) Akim> add_depend2 (c) Akim> add_depend2 (objc) Akim> where I would have expected to see lex, yacc etc. I don't think it makes sense to call add_depend2(yacc) or add_depend2(lex). That's because these languages don't know how to do dependency tracking. Or, more precisely, or yacc and lex we can do the dependency tracking statically because neither yacc nor lex has an include facility. These are marked "derived autodep" which means that the yacc output is subject to automatic dependency tracking. E.g., seeing foo.yy should result in a call to add_depend2(cc), even if no other .cc file is in the project. Akim> * automake.in (&handle_single_transform_list, &finish_languages) Akim> (&handle_dist, &handle_dependencies): Use the language object for Akim> autodep and derived-autodep too. I think this is ok. Ultimately we'd like to excise these special cases and have the yacc language object itself know how to make calls into the C (or C++, or ...) language object for further processing. Tom
Re: 79-lang-compile.patch
One last thing about separating into modules: we'll probably want to put the module files into their own directory in the source and install trees. Let's start a new directory for this sooner rather than later. Tom
Re: 81-lang-extensions.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in: (Language): Add attribute `extensions'. Akim> (Automake): Pass a hash to `®ister_language' instead of a Akim> list of pseudo assignments. Akim> (®ister_language): Adjust. Akim> (&finish_languages): Initialize `$ltoutarg'. Ok. Tom
Re: 80-lang-finish.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (Language): Add attribute `output_arg'. Akim> (%language_map): Remove. Akim> (®ister_language): Build only the object, and store in Akim> %languages only. Akim> (&finish_languages, &handle_single_transform_list): Adjust. Ok. Tom
Re: 79-lang-compile.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Tom> But do we really want objects with public attributes? It seems Tom> to me that we'd probably rather have objects with public methods Tom> and private attributes. Akim> Nevertheless, in the present case, these are not exactly Akim> attributes, which _are_ hidden. BTW, one thing I'm getting at here is that if we have special cases on the language, then these special cases should be made into methods on the language object. Sometimes this might not be worth doing (when a piece of code needs cross-language knowledge), but often times it will. Tom
Re: 79-lang-compile.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (Language): Add attributes `flags', `compile' and Akim> `compiler'. Akim> (&finish_languages, &handle_single_transform_list, &handle_dist) Akim> (&add_depend2, ®ister_language): Use them and the `linker' and Akim> `pure' attributes. Ok. Tom
Re: 77-language-class.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (Language): New package, temporarily in this file.
Akim> Use Class::Struct.
Akim> (Automake): New package.
Akim> (%languages): New.
Akim> (&handle_single_transform_list): Use the language object's `ansi'
Akim> attribute instead of `$language_map{"$lang-ansi-p"}'.
Akim> (®ister_language): Build and register the language too.
This is ok.
But before we check it in let's make sure we are very clear on the
licensing issue. In GNU, licensing comes before all.
This might mean that we'll be restricted to whatever Class::Struct
comes with the Perl version we decided on. That would be unfortunate,
but we've lived with implementation deficiencies in the past (i.e.,
Perl 4)
Tom
Re: 79-lang-compile.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> Nevertheless, in the present case, these are not exactly Akim> attributes, which _are_ hidden. It's accessors: Thanks. Akim> Anyway, there is a big problem with pushing more language Akim> handling in the class itself, as there is a lot of Automake subs Akim> to use. And then Automake depends upon Automake::Languages Akim> which depends upon Automake. If we continue down the path of modularity we're eventually going to have to sort this out. I think we'll probably have several separate Automake::* packages. I imagine we'll be able to find an ordering which isn't circular. Tom
Re: overriding tested automake & aclocal in test suite
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: Derek> Is there some reason the automake test suite doesn't allow the Derek> user to override its AUTOMAKE & ACLOCAL variables? Thanks for the patch. I wrote a ChangeLog entry for you. Could you write it next time? Tom
Re: Scripts...
> "Alex" == Alex Turner <[EMAIL PROTECTED]> writes: Alex> What is the best way to have a script/program where $pkgdatadir Alex> is located? I assume you mean how to find pkgdatadir in a program? Alex> For C, it's easy enough just to do Alex> CCFLAGS=-DPKGDATADIR="\""$(pkgdatadir)"\"" but what about things Alex> like perl scripts that have to pull option files and such. Is Alex> there a standard way to tackle this? For automake I use AC_SUBST and have @...@ substitutions in automake.in. Tom
Re: Scripts...
> What is the best way to have a script/program where $pkgdatadir is > located? > > For C, it's easy enough just to do > CCFLAGS=-DPKGDATADIR="\""$(pkgdatadir)"\"" but what about things like perl > scripts that have to pull option files and such. Is there a standard way > to tackle this? There may be a better way, but renaming the script to script.in, replacing hard-coded paths with AC_SUBST'd variables (@PKGDATADIR@ etc.) in script.in, and adding the script to AC_OUTPUT in configure.in has worked for me. --Rusty
Scripts...
What is the best way to have a script/program where $pkgdatadir is located? For C, it's easy enough just to do CCFLAGS=-DPKGDATADIR="\""$(pkgdatadir)"\"" but what about things like perl scripts that have to pull option files and such. Is there a standard way to tackle this? Thanks Alex T
Re: Default postscript cleans miss *.cps & *.fns.
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> elsif (/^\@(syncode|print)index \w+ (\w*)/)
Akim> {
Akim> push @clean_suffixes, "$1s";
Shouldn't that be "$2s" here?
Tom
Re: overriding tested automake & aclocal in test suite
Tom Tromey wrote:
> > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
>
> Derek> Is there some reason the automake test suite doesn't allow the
> Derek> user to override its AUTOMAKE & ACLOCAL variables? I like to
> Derek> do it on ocassion to compare the current behavior against my
> Derek> installed version and the like.
>
> No, there's no reason. Send a patch...
Attached.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
I will not carve gods.
I will not carve gods.
I will not carve gods...
- Bart Simpson on chalkboard, _The Simpsons_
Index: defs
===
RCS file: /cvs/automake/automake/tests/defs,v
retrieving revision 1.23
diff -u -r1.23 defs
--- defs2001/03/04 21:05:09 1.23
+++ defs2001/03/23 21:30:05
@@ -71,7 +71,7 @@
# See how Automake should be run. We put --foreign as the default
# strictness to avoid having to create lots and lots of files. A test
# can override this by specifying a different strictness.
-AUTOMAKE="$PERL ../../automake --amdir=$srcdir/.. --foreign"
+: ${AUTOMAKE-"$PERL ../../automake --amdir=$srcdir/.. --foreign"}
# See how aclocal should be run.
-ACLOCAL="$PERL ../../aclocal --acdir=$srcdir/../m4"
+: ${ACLOCAL-"$PERL ../../aclocal --acdir=$srcdir/../m4"}
Re: 79-lang-compile.patch
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: > "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> * automake.in (Language): Add attributes `flags', `compile' and Akim> `compiler'. (&finish_languages, &handle_single_transform_list, Akim> &handle_dist) (&add_depend2, ®ister_language): Use them and Akim> the `linker' and `pure' attributes. Tom> As I've said many times before, I definitely think we want each Tom> language to be an object of some kind. Tom> But do we really want objects with public attributes? It seems Tom> to me that we'd probably rather have objects with public methods Tom> and private attributes. (For all I know they are the same in Tom> Perl. Feel free to educate me :-) I certainly don't have a strong Perl culture, but it is my understanding that this presentation is the tradition (firstly because that's the way Class::Struct is built, and secondly because that's what advocates the advanced Perl programming book from O'Reilly :). Nevertheless, in the present case, these are not exactly attributes, which _are_ hidden. It's accessors: $foo->bar is a method returning the value of the hidden bar attribute, and $foo->bar (baz) sets it. Anyway, there is a big problem with pushing more language handling in the class itself, as there is a lot of Automake subs to use. And then Automake depends upon Automake::Languages which depends upon Automake. Puke puke puke!
Re: Default postscript cleans miss *.cps & *.fns.
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Nope, not yet. I'm downloading CVS to check this.
Well, which one should I download? Where is it? Releases don't use
Automake, Thomas was right ;)
Derek, could you patch your automake so that in scan_texinfo, this
elsif (/^\@syncodeindex \w+ (\w*)/)
{
push @clean_suffixes, "$1s";
}
become (hm, no `s' here, right?)
elsif (/^\@(syncode|print)index \w+ (\w*)/)
{
push @clean_suffixes, "$1s";
}
and try again? At least *.cps should be caught. I need more data for
*.fns.
Re: Default postscript cleans miss *.cps & *.fns.
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes: >> I really think we can discover them all. The thing is that index >> can be created at will. So unless you actually look for used >> indexes, you can never be sure you don't forget something. Tim> Wouldn't using the -c option to texi2dvi solve this? That way, Tim> the index files don't need to be cleaned in the first place. Unfortunately it is a `recent' addition: 4.0. In fact, I'd like to implement texi2dvi --clean-files, which is what Automake really needs, but that's too late for Automake (unless we start shipping texi2dvi...).
Re: Default postscript cleans miss *.cps & *.fns.
> I really think we can discover them all. The thing is that index can > be created at will. So unless you actually look for used indexes, you > can never be sure you don't forget something. Wouldn't using the -c option to texi2dvi solve this? That way, the index files don't need to be cleaned in the first place.
Re: problem with conditionals and \ separator in SOURCES
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes: >> Am I doing something wrong? >> Notice that this problem only takes place with cygwin Tim> Might be an EOL issue; sed is notorious for not recognizing a trailing \ Tim> in a DOS text file (it sees \ + CR + NL). Tim> Try converting the file to Unix text. Tim> Note: this is just a hunch. Sounds like a good hunch to me. Automake 1.4 didn't try to deal with DOS-style line endings correctly. For that matter I don't know whether the cvs automake does. It does set `binmode' on its output, but it might not handle \r\n in its input too well. Lorenzo, can you check this? Tom
Re: 76-tags-in-tags-am.patch
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> Then, I'd say we should have TAGS work all by itself, calling Akim> TAGS-recursive. And tags is nothing but `tags: TAGS'. How does Akim> it sound? Sounds good to me. Tom
Re: Default postscript cleans miss *.cps & *.fns.
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: > "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: Derek> FYI: the *.cps & *.fns files are only being created for Derek> cvs.texinfo. Tom> Did we ever get some resolution for this? Nope, not yet. I'm downloading CVS to check this. Tom> Akim, I recall you had a patch which removed a large number of Tom> file extensions from the texinfo clean list. Perhaps these Tom> should be added back? (I really don't know whether these can be Tom> discovered automatically. I don't know that much about tex.) I really think we can discover them all. The thing is that index can be created at will. So unless you actually look for used indexes, you can never be sure you don't forget something.
Re: 76-tags-in-tags-am.patch
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: > "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Akim> This patch introduces one semantical difference: tags-recursive Akim> is bound to tags, not TAGS as was before. I think (i) it is Akim> cleaner, and (ii) anyway it seems to me that TAGS itself Akim> performs its own recursion: Tom> The "recursion" in TAGS is different. tags-recursive should be Tom> running `make tags' in each subdir. In TAGS we look for a TAGS Tom> file in each subdir and if it exists we include it in the TAGS Tom> file we are creating. Ah! That's the thing. Thanks! Tom> The thing is that `tags' is really a convenience for people who Tom> don't like upper case. It is a historical thing and not Tom> mandated. TAGS is the name of the mandated target. Hm, it's seems a bit contradictory: tags is a convenience for TAGS, but it's different? Tom> So I think `make TAGS' has to do all the recursion. Maybe we Tom> currently get this wrong, since the recursive invocation invokes Tom> `make tags' and not `make TAGS'. I'm tempted to understand you say the same thing (tags: TAGS period), but I'm not sure. Akim> Another question is why don't we use the regular -am, -recursive Akim> mechanism? Given that we always output a `tags' and `TAGS' Akim> target, it should be equivalent and much simpler: just Akim> RECURSIVE_TARGATS += tags-recursive. Tom> Because the recursive tags invocation should never fail. Maybe Tom> it is ok if a tags failure in a subdir propagates upwards, since Tom> it means there's a bug somewhere. I'm ok with that change if you Tom> want to make it. Given that local TAGS targets cannot fail, I'd say we should hook ourselves on the regular mechanism. Then, I'd say we should have TAGS work all by itself, calling TAGS-recursive. And tags is nothing but `tags: TAGS'. How does it sound?
RE: problem with conditionals and \ separator in SOURCES
> cmdline.c \ > main.cc errors.cc stringtable.cc tables.cc nodevis.cc \ > > and the problem seems to be that \ in myprog_SOURCES is not recognized! > > Am I doing something wrong? > Notice that this problem only takes place with cygwin > Might be an EOL issue; sed is notorious for not recognizing a trailing \ in a DOS text file (it sees \ + CR + NL). Try converting the file to Unix text. Note: this is just a hunch.
Re: CVS autoconf + CVS automake = autoconf doesn't know its version
Fine! Please, install.
Re: CVS autoconf + CVS automake = autoconf doesn't know its version
On Tue, Apr 10, 2001 at 10:30:12AM +0200, Akim Demaille wrote: : I prefer Raja's solution for the very reason he described. It's : really a problem between Automake and aclocal.m4, so it should be : fixed there, or in configure.in. aclocal.m4 was so neat and tidy that I put it in configure.in: Index: Makefile.am === RCS file: /cvs/autoconf/Makefile.am,v retrieving revision 1.44 diff -u -r1.44 Makefile.am --- Makefile.am 2001/04/09 19:30:50 1.44 +++ Makefile.am 2001/04/10 11:51:11 @@ -30,12 +30,6 @@ bin_SCRIPTS = autoconf autoheader autoreconf ifnames @PERLSCRIPTS@ EXTRA_SCRIPTS = autoscan autoupdate -# FIXME: Current Automakes are blind and cannot see inner AC_SUBST, -# so help it. This is because, in this case, 'aclocal' is bypassed. -PACKAGE_NAME = @PACKAGE_NAME@ -VERSION = @VERSION@ -PACKAGE = @PACKAGE@ - # FIXME: # s/distpackageDATA/dist_pkgdata_DATA/ # s/nodistpackageDATA/nodist_pkgdata_DATA/ Index: configure.in === RCS file: /cvs/autoconf/configure.in,v retrieving revision 1.43 diff -u -r1.43 configure.in --- configure.in2001/03/27 12:02:16 1.43 +++ configure.in2001/04/10 11:51:11 @@ -43,6 +43,12 @@ AC_SUBST(standards_texi, standards.texi)dnl fi +# Automake can't see inner AC_SUBSTS (`aclocal' is bypassed), so we tag the +# AC_SUBSTS here too. +AC_SUBST(PACKAGE_NAME) +AC_SUBST(PACKAGE) +AC_SUBST(VERSION) + AC_OUTPUT(Makefile m4/Makefile man/Makefile doc/Makefile tests/Makefile tests/atconfig)
Re: CVS autoconf + CVS automake = autoconf doesn't know its version
| On Fri, Apr 06, 2001 at 12:17:47PM -0500, Raja R Harinath wrote: | : @PACKAGE@ is needed. It is used by Makefile.in for 'make dist'. | : | : "Lars J. Aas" <[EMAIL PROTECTED]> writes: | : > Index: Makefile.am | : > === | : > @@ -33,6 +33,7 @@ | : > # FIXME: Current Automakes are blind and cannot see inner AC_SUBST, | : > # so help it. | : > PACKAGE_NAME = @PACKAGE_NAME@ | : > +VERSION = @VERSION@ | : | : I feel this is the wrong place. The locus of the problem is the | : bypassing of 'aclocal' -- so 'aclocal.m4' is the best place to fix | : it. | : | : Take a casual reader familiar with automake, and who doesn't remember | : that 'aclocal' is bypassed. The above line will look superfluous -- | : after all, in every other package using automake, that line would be | : superfluous. At a minimum, please place a comment on that line. | | I've attached the minimum solution below, which I think I can just apply | without approval to get this fixed (it's really just a correction to the | previous patch that was OK'd). I see your point, though, but want some | other maintainer's opinion on it before moving the fix into aclocal.m4. | I assume PACKAGE_NAME will be moved along with VERSION and PACKAGE? | If I don't hear anything during the day, I'll just commit the below patch. I prefer Raja's solution for the very reason he described. It's really a problem between Automake and aclocal.m4, so it should be fixed there, or in configure.in.
Re: Including foreign makefiles
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> Your particular include doesn't match the regexp.
Tom> I'm not sure why I did it that way initially. Now that seems
Tom> like a bug to me.
Agreed.
Tom> Instead I think anything we don't recognize should simply give an
Tom> error.
Well, you certainly don't mean ``anything'' :) So I guess we should
use a scheme based on /^keyword / instead of the current scheme. But
this should be applied to all the keywords (if, else etc.). Bleah,
it's going to make the code uglier...
Or maybe just:
...
elif (/^(if|else|endif|include)\b/)
{
echo "Nia: %s\n", $_ >&STDERR;
throw Failure ();
}
(Hm, we should rewrite Automake in INTERCAL :)
problem with conditionals and \ separator in SOURCES
Hi In configure.in I have these lines AC_PATH_PROGS(GENGETOPT, gengetopt) AM_CONDITIONAL(NO_GENGETOPT, test -z "$ac_cv_path_GENGETOPT" ) and in src/Makefile I have SUFFIXES = .ggo if NO_GENGETOPT .ggo.c: touch $@ else .ggo.c: $(GENGETOPT) --input $< --unamed-opts endif under Linux there are no problems, while with cygwin, and automake $ automake --version automake (GNU automake) 1.4 which looks the same under Linux, the conditional is not substituted, i.e. in src/Makefile I have if NO_GENGETOPT .ggo.c: touch $@ else .ggo.c: $(GENGETOPT) --input $< --unamed-opts endif cmdline.c \ main.cc errors.cc stringtable.cc tables.cc nodevis.cc \ and the problem seems to be that \ in myprog_SOURCES is not recognized! Am I doing something wrong? Notice that this problem only takes place with cygwin thanks in advance Lorenzo -- +-+ | Lorenzo Bettini ICQ# lbetto, 16080134 | | PhD student in Computer Science| | Florence - Italy (Linux User # 158233) | | Home Page: http://w3.newnet.it/bettini | | http://infostud.dsi.unifi.it/~bettini | | Mail : [EMAIL PROTECTED]| | http://www.mokabyte.it Java on line journal | | http://music.dsi.unifi.it XKlaim language | | http://w3.newnet.it/bettini/purple Cover Band | | http://www.gnu.org/software/java2html & cpp2html | +-+
