> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * tests/specflags4.test, tests/specflags5.test: Remove, merged
Akim> into...
Akim> * tests/specflags3.test: here.
Ok. But why bother?
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I'm very surprised by:
Akim> +EXPECT = `if test -f $(top_builddir)/../expect/expect; then \
Akim> ++
Akim> +echo $(top_builddir)/../expect/expect; \
Akim> + else \
Aki
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> So finally, I have Automake skip Automake definitions when a
Akim> user value is already defined.
Thanks. This is how automake has always worked. It is even
documented as working this way.
In theory this should happen for rules a
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&scan_texinfo_file): Catch @cindex and the like,
Akim> but also @deffn and so on which push data in indexes.
Akim> Reported by Derek R. Price.
Thanks for following up on this.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Tom, is this enough for us to use it?
I don't know.
I think we have to ask RMS.
Could you do that?
Tom
I removed cpan from the CC ilst.
rms> Does "no license changes" mean that the modified version is also
rms> released with notices saying "dual Artistic | GPL"? In that
rms> case, the situation seems perfectly explicit and clear.
Akim, I'm satisfied that we're ok distributing our own Class::Stru
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
> On Tue, Apr 17, 2001 at 09:30:08AM +0200, Jens Krüger wrote:
> : What is the meaning of the '--amdir=DIR' option?
Lars> To specify another dir for the Automake templates you usually find in
Lars> /usr/share/automake/ or /usr/local/share/au
> "Raj" == Raj (Basavaraj) Karadakal <[EMAIL PROTECTED]> writes:
Raj> I am trying to use Automake in a project. I found a dependency
Raj> problem in the generated Makefile. If I change Makefile.am , the
Raj> dependency rules in the Makefile to update itself, will not be
Raj> executed before t
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Well, I have no experience at all in this area, so here is my
Akim> proposal. I must leave now, sorry I didn't write the full
Akim> ChangeLog. Of course I will.
Akim> Tom?
Maybe we should introduce a new subdirectory in the sourc
> "Raj" == Raj (Basavaraj) Karadakal <[EMAIL PROTECTED]> writes:
Raj> I am using clearmake in gnu compatibility mode.
Maybe it is a bug in the compatibility mode then.
With GNU make, any `Makefile' target is processed before all other
targets. If the Makefile is rebuilt then it is re-read
Pavel> This patch has been tested with Perl perl5.005_03 and 5.6.0. Ok
Pavel> to apply?
Akim> Fine with me.
Me too. Thanks.
Tom
> "David" == Zhu, David <[EMAIL PROTECTED]> writes:
David> Could you send me examples of how to use autoconf and automake.
http://sources.redhat.com/autobook/
Tom
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
I finally read this thread.
Robert> cf_gen_SOURCES = cf_gen.c defines.h
Robert> nodist_cf_gen_SOURCES = cf_gen_defines.h
Robert> BUILT_SOURCES = cf_gen_defines.h
Robert> I think cf_gen_defines.h should be one of the dependencies of
Ro
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> On a related note, I wonder if it would be reasonable to add a
Robert> test case to Automake similar to the style that Libtool uses.
Robert> A test that actually compiles code and attempted to use
Robert> dependencies, invoke lib
> "Paul" == Paul F Kunz <[EMAIL PROTECTED]> writes:
Paul> To answer my own question about bad dependency generation with
Paul> the combination of Red Hat 7.1beta, gcc 2.96, and
Paul> autoconf/automake released version. It is gcc 2.96 causing the
Paul> problem, as it went away after installin
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> foreach my $iter (@deplist)
Robert> {
Robert> $output_rules .= (' @_am_include@ @_am_quote@'
Robert> . $iter . '@_am_quote@' . "\n");
Robert> }
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> This is just a patch for the fix suggested to me.
Robert> + 'uninstall-am' =3D> 1,=0A=
I checked this in.
Thanks.
Tom
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> I'm currently having to distribute two patches for automake to
Robert> achieve the pass on make distcheck - the openbsd install-am
Robert> target, and the workaround I put together for subobj5.test. If
Robert> you guys have some
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> 2001-04-25 Robert Boehne <[EMAIL PROTECTED]>
Robert> * configure.in: Add _am_dep_true='@AMDEP_TRUE@' and AC_SUBST it.
Robert> * automake.in: (handle_dependencies) Replace @AMDEP_TRUE@ in
Robert> $output_r
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Applied after a short fight with CVS. The version you are using
Pavel> on sourceware.cygnus.com tends to commit only some of the files
Pavel> in a single run (either only those from the current directory
Pavel> or all files except t
> "Richard" == Richard Boulton <[EMAIL PROTECTED]> writes:
Richard> The gstreamer project, however, has a Makefile.am with
Richard> conditionals for each of a set of conditions dictating which
Richard> SUBDIRS are to be built. The file currently has 16 separate
Richard> conditionally defined
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> * automake.in (scan_texinfo_file): Don't push undefined values
Pavel> to @clean_suffixes.
Pavel> -push @clean_suffixes, $predefined_index{$1};
Pavel> +push @clean_suffixes, $predefined_index{$1}
Pavel> +
> "Patrick" == Patrick Welche <[EMAIL PROTECTED]> writes:
Patrick> From configure:
Patrick> checking whether make sets ${MAKE}... (cached) yes
This means that make sets the make variable `MAKE'...
Patrick> From defs:
Patrick> # User can set MAKE to choose which make to use. Must use GN
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Russ> Since it's pretty unlikely that there's going to be another
Russ> Automake::Class floating around, that should be equivalent,
Russ> except that it has the nice plus of then let
> "Dave" == Dave Morrison <[EMAIL PROTECTED]> writes:
Dave> I have a project in which there are some header files (they
Dave> happen to have the suffix `.idl') that I want installed.
Dave> Nothing else in the project depends directly on them, I'd just
Dave> like to install them.
Dave> includ
> "Felix" == Felix Natter <[EMAIL PROTECTED]> writes:
Felix> I created a minimal "hello-world"-package for this:
Felix> http://www.ndh.net/home/natter/hello-1.0.tar.gz
Congratulations -- you found a `make dist' oddity that we never
considered.
The problem is that by default we use `ln' to m
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes:
Ralf> Related question: Which directory is am_dir/--am-dir supposed to
Ralf> point to, now? <..>/automake/ or <..>/automake/am?
Akim> Good question. No idea what Tom will prefer.
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&finish_languages): Rename as...
Akim> (&handle_languages): this.
Akim> Include the body of...
Akim> (&handle_dependency): this.
Akim> Remove.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_languages): Don't use $comp.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_languages): Compute `$ltoutarg' and
Akim> `$outarg' independently from dependency code.
Akim> There is no use looping on a language's possible extensions since
Akim> we loop over used extensions.
Akim>
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_languages): Use the same `%transform' for
Akim> both `depend2.am' and `ext-compile.am'.
Akim> Move the definition of `$flag' where it is used, and rename as
Akim> `$flags'.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_languages): Don't transform %COMPILER%.
Akim> Use `$lang->compiler' instead of `$pfx' to transform generic
Akim> %COMPILE% and %LTCOMPILE%.
Akim> * ext-compile.am: Use %COMPILE%, %COMPILER% and %SOURCE%
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (Language): Replace the attribute `output_arg' with
Akim> `compile_flag' and `output_flag'.
Akim> (Automake): Adjust language registrations.
Akim> (&handle_languages): Transform `-c' and `-o' for both suffix and
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_languages): `ext-compile.am' and
Akim> `depend2.am' are now equivalent for generic rules: output only the
Akim> latter.
Akim> * ext-compile.am: Remove.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Uniform handling of per-object compilation rules.
Akim> * automake.in (&handle_languages): Output per object rules for all
Akim> the objects, not only for those which language supports dependency
Akim> tracking.
Akim> When
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in: Formatting changes.
Akim> (variable_dump, variables_dump): Rename as...
Akim> (macro_dump, macros_dump): these.
Ok.
I think if we agree on what something should be called then simple
renaming patches like this d
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Support `if !COND', `else COND', `end COND'.
Akim> * automake.texi (Conditionals): Document it.
Akim> * automake.in ($WHITE_PATTERN, $MACRO_PATTERN, $BOGUS_MACRO_PATTERN)
Akim> ($GNITS_VERSION_PATTERN, $INCLUDE_PATTERN): Use
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&define_compiler_variables): Use only $LANG as
Akim> argument.
Akim> (&handle_languages): Adjust.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> The goal is to handle LINK and the like just the way we handle
Akim> COMPILE and the like. First I have to understand completely
Akim> what's so special wrt C, but I'm confident we can reach
Akim> something generic and shorter (many
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&handle_lib_objects_cond): Don't take $LEX_SEEN as
Akim> argument, as you don't use it.
Akim> Hence...
Akim> (&handle_lib_objects): Don't take $LEX_SEEN as argument, as you
Akim> don't use it.
Akim> Hence..
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (Language): Add attributes `lder' and `ld'.
Akim> (®ister_language): Specify for cxx, objc, f77, gcj.
Akim> (&define_linker_variable): New.
Akim> (&lang_cxx_finish, &lang_f77_finish, &lang_objc_finish)
Akim> (
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (Language): Add attributes `Name' and `config_vars'.
Akim> (&finish): Work properly if there is no _finish.
Akim> (Automake): Register language Names and AC_SUBST dependencies.
Akim> Register Fortran 77 variable
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (&file_contents_internal): Accept $IS_AM.
Akim> (&handle_compile, &define_standard_variables, &file_contents):
Akim> Adjust.
Ok.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (am_install_var): Use `next' instead of `if' on the
Akim> body of $X loop.
Ok.
Tom
Akim> I'm stuck. I tried to produce the single big patch which
Akim> consists of them all, but after having fought with patch, I
Akim> realized I must have forgotten a patch: that introducing
Akim> handle_languages.
Which patches does the 97.5 patch supercede?
Here are patches I still have:
Pa
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Still getting closer to what Tom doesn't want: the read_am_file
Akim> removal. I would be lying if I pretended that this removal was
Akim> easy: pretty many weaknesses in file_contents weaknesses are
Akim> uncovered by the test suit
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> Quite straightforward (oh, how I love *.am only patches :). The
Akim> only question is whether we want to factor tar too or not.
It's up to you. It doesn't matter to me.
Akim> * distdir.am (dist-all): Build all the flavors usin
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> When I run automake in certain projects, I get the below
Lars> attached output. It's been like this for a while (figured it
Lars> was a known issue that would soon get fixed), but now I suspect
Lars> that I'm the only one who gets them
Akim, what do you think of this patch?
2001-05-05 Tom Tromey <[EMAIL PROTECTED]>
* automake.in (conditional_true_when): Use a hash, not index().
Also, a TRUE component always results in a true return.
Fixes test cond10.test. For PR automake/164.
I think the ol
t calling "install-info" in that case,
Peter> but "uninstall" does not.
The rules in texinfos.am look like they both do the same thing
regarding install-info.
Peter> Tom Tromey said to me something along the lines that uninstall
Peter> is of too little use to bother
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> A short while before the libtool-1.4 release, Edward M. Lee
Gary> posted a joint patch to libtool and automake which takes care of
Gary> the worst of this sort of thing. I applied the libtool parts
Gary> before the release but the
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> I understand. However
Robert> cf_gen.$(OBJEXT): cf_gen_defines.h
Robert> is somewhat ugly for an automake file :]
I agree.
Perhaps it would make sense to add a dependency like this in the
"dependency tracking allowed but disab
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
>> +grep ($cond_vals{$_} = 1, split (' ', $when));
Russ> It's generally considered poor Perl coding style to use grep for
Russ> its side effects alone without checking the return value.
Thanks. This idiom is used all over automake, b
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> * automake.in (scan_texinfo_file): Consider @defindex and
Pavel> @synindex in the same way as @defcodeindex and @syncodeindex
Pavel> respectively.
I think this is ok.
Please check it in.
Pavel> + elsif (/^\@def(code)?index
Is there any reason not to simply delete objc.test?
Tom
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> By the way, I discovered a terrible bug in CVS Automake while
Pavel> testing it - "make dvi" doesn't propagate to the
Pavel> subdirectories.
>> That's a bit suprising. I looked at the automake Makefile.in and it
>> seems to do the
Pavel --
I checked in a test for the dvi problem you reported.
The problem is that dvi is only made recursive when texinfos.am is
included. However that is only included when texinfo is seen.
This is wrong. A recursive target must be recursive whenever SUBDIRS
is seen.
This problem only seem
> "Sam" == Sam TH <[EMAIL PROTECTED]> writes:
Sam> [sam@samth build]$ automake --version
Sam> automake (GNU automake) 1.4a
Sam> I hope this is enough info for someone to figure out what is
Sam> going wrong.
Unfortunately `1.4a' only tells us that it was a cvs snapshot.
Do you know when you
> "Lorenzo" == Lorenzo Bettini <[EMAIL PROTECTED]> writes:
>> Automake 1.4 didn't try to deal with DOS-style line endings correctly.
Lorenzo> You're right: line endings are to blame... the funny thing is
Lorenzo> that I got the sources from a Linux CVS server, and the
Lorenzo> uncorrect line
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Would you be agreeable to granting me (at least temporary) CVS
Gary> write access so that I can do this?
Sure. I've had several requests for this recently.
One question is what to name the release. This is more of a problem
than
Gary> I notice that you haven't yet migrated the project to
Gary> savannah... is that a deliberate choice, or simply a lack of
Gary> time? I'd be happy to facilitate the migration if you like.
Automake has never been hosted at GNU. Its entire public life has
been at sources.redhat.com. I have
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> The test that check this (which I now ) are
Akim> compile_f_c_cxx.test:foo_SOURCES = foo.f bar.c baz.cc
This one doesn't really test the problem I'm thinking of.
In this case the files are all from different languages.
Akim> subo
I went through all the automake PRs recently. I've changed the
`priority' field to reflect what I think are the 1.5 release
requirements: if a PR has `high' priority then it should be fixed for
1.5.
Feel free to make a case for changes to this prioritization if you
think any are required.
Tom
Shouldn't the prototype for file_contents_internal read `($$%)'?
Tom
Akim> | Akim> * automake.texi (Conditionals): Document it.
Tom> | Ok.
Tom> | Could you update automake.texi to reflect this change?
Akim> :)
Oops. I thought I looked at the patch and didn't see a .texi change
there. Thanks.
Tom
ha will be in the distribution.
Instead, could you port this change over?
2001-05-06 Tom Tromey <[EMAIL PROTECTED]>
* automake.in (GNITS_VERSION_PATTERN): Document. Add `fork
identifier'.
(handle_options): Handle fork identifier in version number.
Then you c
Russ> Well, the effect of -I is just to add things to @INC, so since
Russ> you're modifying @INC with Perl code, one can potentially take
Russ> the effects of -I into account and not override them. The
Russ> question is more the best way of doing that.
Akim> Yep, I did not unroll the whole think
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> + return 1 if $comp eq 'TRUE';
Akim> + return 0 if ! defined $cond_vals{$comp};
Akim> I don't understand why you had TRUE here. I mean, it seems to
Akim> me it's a `next' not a return. Conditionals are conjunctions,
Akim> not disj
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I would like to move the documentation into doc/ in Automake.
Akim> OK with that? Same problem as for *.am files, Tom, we need to
Akim> move them on the CVS server if we want to keep the history.
I would like to keep the history.
I
Akim> * automake.in (@objects): Remove, unused.
Akim> Remove all the code related to it, and to former `$(OBJECTS)'.
Ok, thanks.
Tom
Pavel> Un-flattenning Automake is probably a good idea, but the
Pavel> history is a serious concern, especially considering that the
Pavel> output of "cvs annotate" will be affected.
My plan is to copy the `,v' files on the repository and then remove
all the tags in the copies. Then I will `cvs
Akim> * automake.in (&handle_single_transform_list): Simplify
Akim> computation of $object and $this_obj_ext.
Akim> * tests/lex3.test: Merge into...
Akim> * tests/lex.test: here.
Akim> * tests/pr19.test: Improve and rename as...
Akim> * tests/lex3.test: this.
Feel free to check this i
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Let me know if you are happy with the results (or if there are
Gary> any other obvious fixes you would prefer to apply first) and I
Gary> will roll up the release and put it up on ftp.gnu.org.
It looks good to me.
There is a releas
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> I noticed after uploading that you haven't made diffs or xdeltas
Gary> for your other releases. I can delete the new diff and xdelta
Gary> if you like.
You can leave them. Historically automake releases have been
characterized by
> "Felix" == Felix Natter <[EMAIL PROTECTED]> writes:
>> AM_INIT_AUTOMAKE should be doing that already.
>> Why does it detect gtar when you don't have it?
Felix> no, there is a line "TAR = gtar" in Makefile.in, so this is
Felix> probably decided by automake.
What version are you using again
> "Stephan" == Stephan Beal <[EMAIL PROTECTED]> writes:
Stephan> I now sometimes wonder if automake's output (or even required
Stephan> user inputs, like all source and header filenames) couldn't
Stephan> be cut drastically by simply taking advantage of more of
Stephan> make's features
Unfor
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> It was funny to see 502 in makefiles and wonder what it might be :-)
Believe it or not, this has happened so many times that whenever I see
strange numbers in a Makefile I know it is a quoting bug in automake.
Tom
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> I thought we fixed this (twice), but I'm still seeing it:
I don't see the bug I know of in the sources.
We use this code to test:
if eval "$MISSING --run true"; then
Does this appear in your configure script?
Maybe there is
Pavel> The next thing I tried was adding "--Werror" to the automake
Pavel> flags in tests/defs. Just four tests now fail unexpectedly (due
Pavel> to warnings that are now errors):
I think adding this is fine for now.
I'm checking in the tests/defs change as well as fixes for the two
bugs. Thank
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> I'll update automake again. Strange - I've tried to keep
Harlan> automake reasonably up-to-date.
Are you using the cvs repository at GNU? If so, then that's the wrong
one.
Harlan> Would you prefer I used the wrapped tarball or
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> Does one of the bugs have to do with being unable to find ansi2knr?
Nope. The known bugs are in gnats (none of which have to do with
ansi2knr) and some existing xfailed tests.
Harlan> Looks like a dependency is wrong/missing an
> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes:
Harlan> And is another problem that the rules that handle ansi2knr
Harlan> conversion create an empty foo_.c file if ansi2knr doesn't
Harlan> exist?
It is possible. I don't know.
Tom
> "Rod" == Keenan, Rod <[EMAIL PROTECTED]> writes:
Rod> I'm using automake 1.4 and libtool 1.3.
1.4 handled BUILT_SOURCES in a fairly dumb way.
I would recommend not using BUILT_SOURCES with that automake.
Rod> BUILT_SOURCES = db_dequeue_generic_tcp_msg.c db_enqueue_generic_tcp_msg.c
make
> "Rod" == Keenan, Rod <[EMAIL PROTECTED]> writes:
Rod> I'm still trying to get this to work. I modified the SUFFIXES
Rod> line to eliminate the .o reference.
Rod>was: SUFFIXES = .o .c .pc
Rod>now: SUFFIXES = .c .pc
If this changes things then I think this is probably an automake bu
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Automake should probably warn about indented comments that go
Pavel> to Makefile.in, as they may be non-portable. I just saw a
Pavel> report in [EMAIL PROTECTED] that Compaq Tru64 UNIX V5.1 doesn't
Pavel> like '&' in such comments,
> "Rod" == Keenan, Rod <[EMAIL PROTECTED]> writes:
Rod> The problem turned out to be that the .pc.c: was reversed and
Rod> needed to be .c.pc: instead.
Hmm, that sounds wrong.
Old-style suffix rules are of the form `.SRC.DEST:', where `.SRC' is
the source extension and `.DEST' is the destin
Derek> What's $(top_builddir)/.deps get used for when there aren't any C
Derek> sources in $(top_srcdir) or $(top_builddir)?
Thanks, I checked in the fix.
Tom
Tom> My reading is that this patch always generates an aclocal.m4
Tom> target, regardless of whether one is warranted.
Akim> Hm, no. I think you missed the first lines of the patch, or I
Akim> might have misunderstood what you mean:
I saw that code.
To me it looks like handle_aclocal_m4 is cal
> "Jim" == Jim Meyering <[EMAIL PROTECTED]> writes:
Jim> It was only a problem when $@ was a shell built-in, like : or cd.
Ok, I re-read your message. Why do we ever run `missing --run :'?
That seems weird.
Tom
> "Lars" == Lars J Aas <[EMAIL PROTECTED]> writes:
Lars> BUILT_SOURCES = header.h
Lars> # build $(BUILT_SOURCES) before entering subdirs
Lars> Makefile: $(BUILT_SOURCES)
Note this will only work with GNU make and is relatively bad besides.
Eg, try `make clean' and watch it rebuild the header
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes:
Robert> Is this a known bug? Am I doing something wrong?
I don't think it is known. There shouldn't be anything for you to do
wrong -- this should work automatically.
Thanks for the report. If it isn't a pain for you could you submi
Akim> Now the question is how will be install it? Do we try to get
Akim> into Perl's packaging system, or just have some pkglibdir and
Akim> install it in there? The same question will arise when we move
Akim> Language, Macro, Rule etc. out of automake.in.
What do we gain from trying to make it
> ">" == Raja R Harinath <[EMAIL PROTECTED]> writes:
>> from Raja R Harinath <[EMAIL PROTECTED]>
>> * automake.in (ASSIGNMENT_PATTERN): Make variable-name pattern
>> stop at the first '='.
Thanks, I checked this in.
Tom
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> * automake.in (Language): Set config_vars for yacc, yaccxx, lex,
Akim> lexxx, asm.
Akim> (&lang_c_finish, &lang_yacc_finish, &lang_lex_finish): Simplify.
Akim> (&lang_asm_finish): Remove, set asm's finisher to C's one.
Ok.
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> For uniformity, I must confess I'd like to see depend2.am
Akim> renamed ext-compile.am.
It is fine with me.
Akim> Tom, I realize I don't understand how Java is handled. There
Akim> are two Javas? On via gcj which is handled thank
Akim> * automake.in (&scan_texinfo_file, &handle_dist, &handle_gettext)
Akim> (&handle_footer, &handle_factored_dependencies, &handle_emacs_lisp)
Akim> (&am_primary_prefixes): Use `map' rather than `grep'.
Definitely! I think we should use map instead of grep in the future
too.
Tom
> "Steve" == Steve M Robbins <[EMAIL PROTECTED]> writes:
Steve> P.S. I have no clue if this affects automake CVS. But a
Steve> 1.4-p2 would be appreciated!
I don't plan to do it, but if you can convince Gary it is fine with
me.
Steve> 2001-05-12 Steve M. Robbins <[EMAIL PROTECTED]>
Stev
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> If you see yacc4 failing, it doesn't matter. It's just another
Akim> sign of the fact that --add-missing is in bad shape currently.
Akim> What happens is that the /usr/local/automake file is chosen
Akim> instead of that shipped with
gcc3 very nearly does exactly what automake wants in terms of
dependency tracking.
I think that ideally automake should recognize this and avoid using
depcomp when it discovers that the user is using gcc3. In this
situation instead of invoking depcomp we would just invoke gcc like
depcomp does (
Right now m4/depend.m4 sets am_cv_OBJC_dependencies_compiler_type=gcc
whenever doing dependency tracking for OBJC.
I think this is wrong. We might be running gcc3, which we ought to
prefer.
Tom
801 - 900 of 1295 matches
Mail list logo
