> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> It seems to me that Autoconf's job is not to remove unportable
Akim> code written by the user, so it seems wrong to have it remove
Akim> VPATH definitions from Makefiles. Historically I'm sure it was
Akim> useful, in a previous cent
> "John" == John Poltorak <[EMAIL PROTECTED]> writes:
>> Was the Makefile.in generated by automake?
John> How do I tell?
head -1 Makefile.in
John> It would suit me if it was in uppercase, and I'm hoping it was
John> generated in lowercase by mistake through some bug in AUTOMAKE.
This is e
Alexandre> We could surely adjust install-sh so as to take a STRIP
Alexandre> variable into account, and set INSTALL_STRIP (a new
Alexandre> variable, set to the same as `$(INSTALL)' if not
Alexandre> cross-compiling, or to `STRIP=toolchain-strip
Alexandre> $(CONFIG_SHELL) /path/to/install-sh' oth
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Once the `make check' finished, I'll check this in:
Did the bug affect any of the existing test cases?
If not I generally add a new test.
Tom
> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> Aren't we supposed to use GNU guile for all FSF-supported
Bob> script-based tools? In fact, isn't Automake itself intended to be
Bob> eventually re-written in guile?
Yes, that is the intent. I doubt I'll be doing the work though.
> "Geoffrey" == Geoffrey Wossum <[EMAIL PROTECTED]> writes:
Geoffrey> Anyway, here's some of my thoughts about it:
Geoffrey> 1) written in Python
The required language flame war has already started. However I think
the implementation language is the least important thing. The
important th
> "Geoffrey" == Geoffrey Wossum <[EMAIL PROTECTED]> writes:
Geoffrey> I was thinking about this, and I considered another
Geoffrey> possibility. autopkg would scan the Makefile.am to build a
Geoffrey> basic specfile, which the developer could then add pre/post
Geoffrey> install scripts and s
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> AM_CONFIG_HEADER([config.h])
adl> May I suggest the change below? (I browsed the source and didn't
adl> find something similar to unquote_m4_arg, that's quite
adl> surprising; did I missed something?)
This looks good to me.
Akim (et al) --
I have a question about the new `transform' subroutine.
Should it be quoting the substitution string in each case?
Tom
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> 2001-01-19 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
adl>* automake.in (obsolete_rx): Match whole macro names, not substrings.
I'm going to check this in along with the corresponding aclocal.in
fix.
Tom
> "Uwe" == Uwe Hermann <[EMAIL PROTECTED]> writes:
Uwe> I was just browsing the THANKS file of the CVS automake and found
Uwe> a duplicate entry:
Thanks, I fixed this.
Tom
> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
Kevin> * tests/colon7.test: Grep for a couple of AC_OUTPUT problems.
Thanks, I checked this in.
I don't know when I'll fix the bug but it will definitely be before
the next release.
Tom
> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> Can someone explain me the comment before the install-strip
adl> rule: "We can't just set INSTALL_PROGRAM because that might be a
adl> relative path". This comment was added with the following
adl> ChangeLog entry:
If there is
Akim> * vtexi.test: Also check that stamp-vti properly depends upon
Akim> configure.in and the Texinfo source file.
This is ok.
Akim> +set -e
I usually use explicit `|| exit 1' after commands.
But it probably doesn't matter.
Tom
> "trevor" == trevor <[EMAIL PROTECTED]> writes:
trevor> one of the first steps that must take place in order to
trevor> compile is to apply a function called "pswrap" to the "*.psw"
trevor> file to generate both a *.h and a *.c file; much the same as
trevor> using LEX and YACC.
trevor> the
> "Paul" == Paul F Kunz <[EMAIL PROTECTED]> writes:
Paul> I'm trying to get automake to build a Makefile that will update
Paul> the project's `.jar' file whenenver any `.java' files get
Paul> compiled. No success so far. Can someone give me a solution to
Paul> this?
Unfortunately there isn
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> (iii): why the heck does automake include CXX related macros in
Akim> the fileutils Makefile.ins??? This is very confusing to
Akim> autoscan, and frankly, I don't think this is good.
I don't know why. Does configure AC_SUBST(CXX)?
Lars> I know I can override check-TESTS, but I'd prefer not to.
What do you need to do this for?
One way to do your own checking is `check-local'.
I guess we could add `check-hook'.
If you need a particular file built then you can use `check_DATA'.
Tom
Akim> I'll investigate where this is coming from. Can it be sufficient?
Yes.
Tom
> "Michael" == Michael Sweet <[EMAIL PROTECTED]> writes:
Michael> http://www.easysw.com/epm
I haven't tried this, but I read through the web site, and it
definitely looks like what I'd like out of an `autopackage'.
Michael> 1. Provide an install-sh like script that appends the
Micha
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> The patch below gives this on the very CVS Automake package:
Akim> * m4/depend.m4 (AM_DEPENDENCIES): Don't leave `AC_PROG_CC' etc. in
Akim> clear.
Akim> * m4/init.m4: Likewise.
Akim> * m4/sanity.m4: s/conftestfile/conftest.f
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
Tim> However, Emacs Lisp also has 'defadvice' which allows you to
Tim> attach arbitrary code to an existing function in different
Tim> ways. I must admit that whole advice thing strikes me as a little
Tim> insane; it's probably quite power
> "Tim" == Tim Van Holder <[EMAIL PROTECTED]> writes:
Tim> I'd like to add (at some point) a macro that detects the path
Tim> separator used on the _build_ system.
It's fine with me. I'd check a patch implementing it into automake.
I don't know the answer to your problems though.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Aii! I was dreading the day that the Demaillator turned his
sights on automake... and now it has arrived!
Akim> * automake.in (get_object_extension) <$default_includes>: New.
Akim> Use it and &transform.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (handle_texinfo): Use the new $texinfodir instead of
Akim> the removed $texinfo_tex.
Akim> - $texinfo_tex = ('$(srcdir)/'
Akim> - . &dirname (&variable_value ('TEXINFO_TEX')));
Akim> +$texin
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (define_standard_variables): Use &transform instead
Akim> of build_rx.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (handle_libraries, handle_ltlibraries): Use
Akim> &transform.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (handle_single_transform_list): if (@list) { foreach
Akim> (@list) ...} can be written as a simple `foreach' loop.
I didn't read this in enough detail to verify that all that you did
was remove the `if'. However,
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (handle_programs) : Remove, replaced by
Akim> `exeext'.
Akim> Use it, and &transform.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (handle_tags): Use &transform.
Akim> (am_error, am_line_error, am_conf_error, read_am_file): Use
Akim> directly arrays in strings, no need for &join.
Akim> * Makefile.am (maintainer-check): Use grep -w when look
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (prog_error): New.
Akim> Spread its use.
This is fine.
Akim> + &prog_error ("version is incorrect: $VERSION")
Akim> + if ($VERSION !~ /([0-9]+)\.([0-9]+)([a-z])?/);
The automake style is to wr
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (scan_one_autoconf_file): Correctly recognize
Akim> configure.ac.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (handle_tests_dejagnu): New, extracted from...
Akim> (handle_tests): here. Use `.PHONY:'.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * texinfos.am, tags.am, subdirs.am, multilib.am, mans.am: Add a
Akim> .PHONY target.
Akim> * automake.in (handle_texinfo, handle_man_pages, handle_multilib)
Akim> (handle_etags, handle_subdirs): Don't push into @phony.
This
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (add_depend2): Use &transform.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (handle_phony): Sort.
Akim> * automake.in (file_contents_with_transform): Catch `.PHONY:'.
Akim> * check.am: New file.
check.am wasn't in the patch. However, I trust it is just an
extraction from handle_tests.
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&scan_autoconf_config_files): Extract from
Akim> &scan_one_autoconf_file.
Akim> (&scan_one_autoconf_file): Use it.
Akim> (&scan_autoconf_traces): New.
Akim> ($scan_autoconf_files): Use it.
This is fine.
I h
Akim --
Your recent patches broke a couple of test cases.
I looked at the `subobj4' failure. I think the new code in
add_depend2 is wrong.
First, this is wrong:
. &transform ('$(' . $pfx . 'COMPILE)'
=> $rule,
&transform puts @...@ around the
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> BTW, if you know the Emacs settings you use for automake.in,
Akim> would it be possible to `Local Variables:' them? I always have
Akim> to adjust my code by hand, since my tabs are 2 space wide, and
Akim> the braces are not aligned
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> It means that for instance we could have
Akim> a b c: d e f
Akim> in a .am file, and have file_contents_with_transform (provided we
Akim> taught it that a, b and c are special targets) push @a, @b, @c the
Akim> list of d, e and f.
> "Emile" == Emiliano <[EMAIL PROTECTED]> writes:
Emile> I'm trying to create an automake file that has rules to
Emile> uppercase files. For example I have something.ext and I want
Emile> it to create a copy SOMETHING.EXT. I tried with this:
Emile> pkgdata_DATA = SOMETHING.EXT OTHER.EXT
Em
> "Michael" == Michael Bletzinger <[EMAIL PROTECTED]> writes:
Michael> cvs automake (as of this morning) behaves differently than automake
Michael> 1.4. 1.4 scanned the SUBDIR targets to locate Makefile.am's.
That's not the case. Automake has always scanned configure.in to find
the Makefil
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I looked at depend2.am:
Akim> [ ... ]
Isn't it hideous? Eww.
Akim> And I'd like to ask a question: why not using @COMPILE@ instead of
Akim> replacing $(@PFX@COMPILE)? It seems cleaner to me, and less
Akim> surprising for Sunday h
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Ok, this was the "file_contents" patch I referred to and then forgot I
hadn't yet read. Sorry about that.
Akim> * automake.in (file_contents): Remove.
Akim> (file_contents_with_transform): Swap the order of the arguments,
Akim> and
Akim --
Changes to automake shouldn't cause any warnings with `make
maintainer-check'. This is a very quick check that can be run even
for trivial and obviously correct changes (it doesn't run the test
suite).
Right now there are problems:
creche. make maintainer-check
/usr/bin/perl -c
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> 1. Does Automake need to know what are the files that can actually be
Akim>in LIBOBJ, or headers can be included?
Automake wants to know the associated headers as well.
Akim> 2. Do we really care about extra dependencies? In t
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (file_contents): Rewrite: instead of trying to parse
Akim> it line by line, first swallow it completely into $CONTENTS,
Akim> *then*, parse it *paragraph* by paragraph.
I see this went in.
What is the rationale f
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (%factored_dependencies): New.
Akim> (file_contents): Use it.
Akim> (handle_phony): Rename as...
Akim> (handle_factored_dependencies): this.
Akim> * subdirs.am: No need for convolved syntax to declare .PHONY.
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> My `plan' is what I implemented in the patch named
Akim> factored-dependencies.
Thanks. I missed some patches in my inbox last night.
BTW subdirs.am doesn't have .PHONY entries for the *clean-recursive
rules. Is this intentional?
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> First I want to write/enhance a test that fails on this.
Try `make TESTS=subobj4.test VERBOSE=t check'.
That will tell you all about the problem.
Tom
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> by an automake configure script. The problem was in
Derek> AM_CONFIG_HEADERS. I fixed it, but is dependent on the
Derek> autoconf beta.
The next automake must be compatible with the old autoconf. So this
patch can't go in as-is
> "Akim" == akim <[EMAIL PROTECTED]> writes:
Akim> I kept comparing Makefile.in from previous automake with my patched
Akim> versions, and didn't notice this problem.
I just noticed this reading subdirs.am. I didn't look to see if
automake.in still generates the .PHONY entries.
Tom
Akim> My goal was to follow strictly the syntax of Make so that people
Akim> don't have several syntaxes to learn, and more than one way to
Akim> shoot in their foot.
Automake doesn't really support make syntax, it just pretends to.
There are some differences. For instance a macro definition can
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Can there be any non source files which we want to ship?
Yes, sometimes. For instance with ansi2knr support we ship the man
page. I don't know whether this impacts autoconf though.
Tom
Pavel> Another related question before I go ahead and enforce a single
Pavel> standard.
Pavel> Should versobe messages go to stdout or stderr? Automake uses
Pavel> stdout, while all other auto* and aclocal use stderr.
It doesn't matter to me. Please feel free to implement what you think
is corr
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> The case in question is the DEFAULT_INCLUDES variable being
Derek> substituted in as part of DEFS. Since Automake still asumes
Derek> that a call to AC_SUBST(DEFS) is always user-requested and that
Derek> a user request overrides
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> From comp-vars.am:
Derek> DEFS = @DEFS@@DEFAULT_INCLUDES@
Derek> Automake subs some compiler include paths into
Derek> @DEFAULT_INCLUDES@ during the creation of Makefile.ins from
Derek> Makefile.ams so that any headers described i
> "Akim" == akim <[EMAIL PROTECTED]> writes:
Akim> As far as I'm concerned, given that your mark are extremely easy
Akim> to remove, given that most messages are from the experimental
Akim> code, given that I certainly would like to toy with your
Akim> implementation, I'd vote for an inclusi
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (@clean): Remove, replaced by...
Akim> ($dependencies{'clean'}): this.
Akim> Use `&depend' instead of push'ing into @clean.
Akim> (handle_factored_dependencies): For the time being, skip 'clean'.
Akim> (do_one
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (%dependencies): Don't be initialize globally for
Akim> all the files, but in...
Akim> (&initialize_per_input): here.
Akim> (&depend): New.
Akim> (@phony): Replace all occurrences with the corresponding &depen
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> @if HAS_SUBDIRS@
Akim> ...
Akim> @fi HAS_SUBDIRS@
Something like this would be fine. I'd prefer `endif' instead of
`fi'. Maybe in this case the `@'s are redundant. Supporting `else'
might also be good.
Akim> * distdir.am (dist
> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
>> I don't know when I'll fix the bug but it will definitely be before
>> the next release.
Kevin> The bandaid I'm using is below. It seems to work, but it'd be
Kevin> a mistake to assume I know what I'm doing.
I came up with a similar pa
> "Rusty" == Rusty Ballinger <[EMAIL PROTECTED]> writes:
I don't remember replying to this.
Rusty> One problem with the patch is that since the noinst_JAVA stuff
Rusty> is "noinst", there's no install-data-am dependency on
Rusty> "install-noinstJAVA" or classnoinst.stamp, so a "make install"
> "Bob" == Bob Proulx <[EMAIL PROTECTED]> writes:
Bob> After running configure I notice that an empty file "D" is left
Bob> around as trash. I investigated and and found the following.
Thanks for the investigation and clear write-up! This helped me fix
the bug (I think) quickly. Well, qui
> "Ganesan" == Ganesan R <[EMAIL PROTECTED]> writes:
Ganesan> This patch mentions the fact that mentioning a directory in
Ganesan> EXTRA_DIST will also included any CVS/RCS version control
Ganesan> files. An example is given to remove these using a dist-hook
Ganesan> target.
Thanks, I checke
> "Ville" == Ville Laurikari <[EMAIL PROTECTED]> writes:
Ville> I sometimes need to work with AIX (poor me) and noticed that
Ville> the latest version of automake has a portable dependency
Ville> tracking mechanism. It does not work with AIX cc though, and I
Ville> though fixing it myself wo
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> Found another bug in automake's support for dependencies using
Derek> BSD's make. This one is based on the fact that BSD make
Derek> doesn't allow comments to continue on the next line using '\'.
Derek> I just hooked into the exis
> "Hari" == Raja R Harinath <[EMAIL PROTECTED]> writes:
Hari> One approach would be to use $(INSTALL_HEADER) which defaults to
Hari> $(INSTALL_DATA), and allow users to specify a special installer
Hari> if they choose. Of course, it would be nice if 'install' in
Hari> fileutils could be exte
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * m4/regex.m4: Use AC_LIBSOURCES.
Akim> * automake.in (scan_autoconf_traces): Trace AC_LIBSOURCE, not
Akim> _AC_LIBOBJ_DECL.
Ok.
My reading is that the change to regex.m4 doesn't require the new
autoconf but will use it if pr
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * Makefile.am (perl4-check): Remove, we now require Perl 5.
Akim> (maintainer-check): Don't be silent when you find a problem, and
Akim> actually, even specify the locations.
Akim> Also check that @_ is assigned to arrays.
O
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (do_one_clean_target): Don't hard code knowledge
Akim> about libtool, and maintainer-clean.
Akim> * clean.am, libtool.am: Handle these.
The libtool part of this patch is fine.
The other part I don't know. I'd l
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> so naturally the question is: do we really want to keep this
Akim> zillions of pseudo targets? The current automake, indeed, does
Akim> this instead:
Akim> --
Akim> clean-am: clean-this-am
Akim> clean-this-am:
Akim> do th
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (handle_texinfo): No longer hard code the clean
Akim> targets.
Akim> (texinfos.am): Include them.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> This message introduces makesort.pl which is quite handy when you
Akim> change to much the layout of Makefiles, just like my previous patch
Akim> does: it becomes nearly impossible to just diff.
Ok.
This needs a ChangeLog entry. A
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * subdirs.am: This file is the exception: clean recursive targets
Akim> are called by the clean targets, not the clean-am targets.
Akim> Otherwise we have a circular dependency: clean -> clean-am ->
Akim> clean-recursive -> c
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (handle_clean): `-local' targets are bound to `-am'
Akim> targets, not top targets.
Thanks, ok.
Tom
> ">" == marq <[EMAIL PROTECTED]> writes:
>> The last point is annoying, since it prohibits the use of any .F90
>> or even .f95 files in any project that is maintained with automake:
>> it simply doesn't generate the proper dependencies for a library or
>> program - a .F90, .f95 or .F95 is n
> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
Kevin> * automake.in (handle_configure): Call config.status with empty
Kevin> CONFIG_LINKS and CONFIG_COMMANDS when regenerating a file.
Thanks, I'm checking this in.
Kevin> I guess the same effect would be obtained from so
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> The following patch has been applied:
Pavel> +* automake.in (handle_dist_worker): Remove a line that is now
Pavel> +in distdir.am.
Thanks.
Tom
Could somebody with access to the BSD make please try the current cvs
automake and report back?
I've tried to implement support for `.include'. I think it works, but
of course I'm not copmletely sure.
This new code does rely on `MAKE' being set at configure time to the
make that the user plans
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> I see that you are not using the latest and greatest Autoconf.
Nope.
Pavel> Names beginning with AM_ are reserved for
Pavel> macros. Autoconf-2.49c will not allow such names in configure.
Hmm.
Pavel> That's why many tests are fa
Akim> I can't proceed without a full approval of this patch, it is
Akim> required for the next ones.
I thought I gave this, with a couple minor changes requested.
Tom
> "Hari" == Raja R Harinath <[EMAIL PROTECTED]> writes:
Hari> That seems counter to current 'automake' behaviour. IIRC, if
Hari> automake sees a "special" target in Makefile.am, it won't
Hari> generate code for that target. E.g., if the Makefile.am has a
Hari> 'check:' target, the builtin t
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> After another consideration I decided that AM_INCLUDE is not
Pavel> meant to be private since it appears in AC_SUBST.
But it is meant to be private. It is an implementation detail. If we
change the implementation it might just go
> "David" == David Petrou <[EMAIL PROTECTED]> writes:
David> include_HEADERS = pdl_config.h
David> This seems to imply that config.h should _not_ be distributed,
David> like I'm doing above. What's wrong with what I'm doing? If
David> it's really so bad, how do I get around the problem t
> "Per" == Per Bothner <[EMAIL PROTECTED]> writes:
Per> The Autotools book, the automake-1.4 manual, and the
Per> automake-1.4/NEWS all imply that "include" is part of automake
Per> 1.4. So how come it doesn't work, but when I try automake from
Per> cvs it does work?
Maybe it is a bug in th
Akim> * automake.in: Various formatting changes, and modernization of
Akim> Perl constructs.
Akim> (&backname): New.
Akim> (&handle_configure, define_standard_variables): Use it.
Ok.
Akim> - print "Copyright 2000 Free Software Foundation, Inc.\n";
Akim> + print "Copyright 2000, 2
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> A very stupid and mechanic patch, indeed, but it helps me seeing what
Akim> happens. In this patch I took the freedom of introducing a new
Akim> syntax: @FOO@ means `to be substituted', while `?FOO?' means to be
Akim> removed if pos
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> I've attached a slightly more succinct test for the original
Derek> problem I pointed out (distcommon.test). It's nice as a
Derek> perquisite at least, as it doesn't require autoconf or make...
Derek> I'm not quite sure I understa
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
>> I'm checking this in.
Pavel> I'm sorry, but the bug seems to be yours. The new test fails
Pavel> after automake.in changes from revision 1.848 to 1.849.
Oh, I know it is mine..
Pavel> In fact it says directly: "Don't push @inputs ont
I've long considered it a mistake that tests/ChangeLog exists. I
think it should be merged with the main ChangeLog.
How about I rename tests/ChangeLog and we start putting entries into
the toplevel ChangeLog? Any objections?
Tom
>> This area still requires more work. I think I know another case where
>> it can fail: suppose you do `AC_OUTPUT(subdir/foo)' where there is no
>> Makefile.am in subdir? Then I think no rule to rebuild subdir/foo
>> will be generated.
Pavel> I would not call it a "failure" - if Automake doesn
Derek> Checked in? Fixes? I'm not pulling any changes...
I can't explain that. I've seen the commit message and everything.
You aren't using the subversions automake are you?
That is a mirror that doesn't update.
Tom
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes:
Derek> Also, looking at this area of the code reminds me that I sent
Derek> a, unfortunately largish, patch in something over a month ago
Derek> that hasn't been reviewed to my knowledge. The patch was
Derek> intended to fix a misplaced
>> You aren't using the subversions automake are you?
>> That is a mirror that doesn't update.
Derek> Yeah, I am. Where is the other one?
All the info is available via the home page.
http://sources.redhat.com/automake/
Tom
>> What you don't want to do is inline the actual rules.
Akim> That's indeed what I was referring to. Well, I think. What
Akim> were you thinking about? I did not think about parallel
Akim> builds... The transformation above is what is now implemented.
Akim> In fact, what I presented in the p
Tom> Note that the clean-am rules are run from the clean-recursive
Tom> rules in subdirs.am. That happens so that we can force the
Tom> ordering, and it is important. This is true for the ordinary
Tom> (all, install, etc) -recursive rules in subdirs.am as well.
Akim> !!!
Akim> Do we have speci
> "Adam" == Adam J Richter <[EMAIL PROTECTED]> writes:
Adam> EXTRA_PROGRAMS = typedefs
Adam> EXTRA_typedefs_SOURCES = typedefs.l
Adam> It produced the following error:
Adam> automake: Makefile.am: object `typedefs.$(OBJEXT)' created by
Adam> `typedefs.c' and `
This is intentional.
You onl
>> I'd like to also work out a naming scheme for internally generated
>> targets. That way eventually it will be clear what people can rely
>> on and what they cannot. Suggestions here are welcome.
Alexandre> How 'bout `_am-target-name'? (note the leading underscore)
Sounds good.
I've updated
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> I believe that names beginning with am_ are
Pavel> private. I.e. AM_INCLUDE should become am_include. I believe
Pavel> that user code should not do anything with the names beginning
Pavel> with ac_ and am_.
I chose `_am_' instead t
301 - 400 of 1295 matches
Mail list logo
