Hello, Akim!
Is this only GNU Make, or a general property?
/tmp % cat Makefile 21:37 remo
all: foo bar
.PHONY: all foo
/tmp % make 21:37 remo
make: *** No rule to make target `bar',
Akim, everyone;
Is there I way I can simply get the discussion, without the binary/patch
traffic? I would prefer to receive this kind of thing through an update
from a source-control (ie CVS) than copies from email.
Should I sign up on a different list? Should [EMAIL PROTECTED]
be formed?
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* automake.in: Promote local `my' over `local'.
Index: automake.in
--- automake.in Wed, 21 Feb 2001 00:28:50 +0100 akim (am/f/39_automake.i 1.58 755)
+++ automake.in Wed, 21 Feb 2001 18:51:21 +0100 akim
This patch applies the same transformation, factoring, to
install-data, install-exec and uninstall.
Below are first presented the Makefiles of Automake. There is
obviously a problem, which I do not solve in this already too long
patch, but will address later: what do with empty targets. For
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* automake.in (am_install_var): Don't hook on the clean targets
and .PHONY.
* data-clean.am, java-clean.am, libs-clean.am, lisp-clean.am,
* ltlib-clean.am, progs-clean.am, python-clean.am, tags-clean.am:
Tom Tromey [EMAIL PROTECTED] writes:
Akim -local ($sect, %sections, %vlist);
Akim +local (%sections, %vlist);
If you need to keep local here for now that is fine. But if so please
add a big comment explaining why.
Ignore this if this spot is fixed in a later patch. I'm reading
On Feb 20, 2001, "Tim Van Holder" [EMAIL PROTECTED] wrote:
+case "$foo_dir" in
+ [\\/]* | ?:[\\/]) # Absolute
^ missing a `*' here, I suppose
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer
+case "$foo_dir" in
+ [\\/]* | ?:[\\/]) # Absolute
^ missing a `*' here, I suppose
Yep. Good catch.
"Tim Van Holder" [EMAIL PROTECTED] writes:
@bullets are atrocious! We use @minus.
Fine by me. Note that the only two other @itemizes in the manual
both use @bullet.
Arg, to be fixed ;)
I removed the @*, AFAIK it's useless here, and anyway it is
inconsistent with the rest of the doc.
I have successfully used automake-1.4d to build a single library
using multiple subdirectories using:
lib_LIBRARIES = libjunk.a
libjunk_a_SOURCES = src/a/a.c src/b/b.c
But if one of the source is a FORTRAN source, it will not work :-(
Is this a simple or difficult fix?
I really love this
From tests/defs:
# User can set which tools from Autoconf to use.
test -z "$AUTOCONF" AUTOCONF=autoconf
if ($AUTOCONF --version) /dev/null 21; then
has_autoconf=:
needs_autoconf=:
else
has_autoconf=false
needs_autoconf='exit 77'
fi
What's
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel You recently applied a patch to tests/target-cflags.test
Pavel without mentioning it in ChangeLog. Maybe you didn't mean to
Pavel commit that change?
Oops.
Pavel * tests/target-cflags.test: Don't use subshell to configure in
Pavel
"Derek R. Price" wrote:
AUTOCONF='exit 77 '
Excuse me:
AUTOCONF='exit 77 dummy'
to keep the parser eternally happy.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
Every
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim What would you say: make it local (i.e., install-man1 builds
Akim MANS1), or global as it was. If easy, I prefer the first
Akim solution, otherwise backup to the previous state.
The first solution is ok.
But note that install-man1 must
"Paul" == Paul Martinolich [EMAIL PROTECTED] writes:
Paul lib_LIBRARIES = libjunk.a
Paul libjunk_a_SOURCES = src/a/a.c src/b/b.c
Paul But if one of the source is a FORTRAN source, it will not work
Paul :-( Is this a simple or difficult fix?
I'm a bit suprised by this.
How does it not work?
"Derek R. Price" wrote:
"Derek R. Price" wrote:
AUTOCONF='exit 77 '
Excuse me:
AUTOCONF='exit 77 dummy'
to keep the parser eternally happy.
Or almost eternally happy. Due to some wierdness where my Bash only evaluates a
variable as a single command (i.e. ignoring ';', '',
"Derek R. Price" wrote:
test='eval exit 77 dummy'
Whoops. Excuse me. That works in every case except ($test). The subshell created
by parens breaks things. I guess that isn't all that robust.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
Hi,
Is there an easy way to add a new recursive target to a top-level
Makefile.am?
For instance, I have a number of different directories with an "html"
target in them. I'd like to have an easy way to run "make html" from
the top-level without having to maintain a special target at the
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* automake.in: Mying changes.
Index: automake.in
--- automake.in Thu, 22 Feb 2001 20:44:50 +0100 akim (am/f/39_automake.i 1.62 755)
+++ automake.in Thu, 22 Feb 2001 20:53:57 +0100 akim (am/f/39_automake.i 1.62 755)
@@ -1509,9
Index: mans.am
--- mans.am Wed, 21 Feb 2001 21:04:28 +0100 akim (am/g/24_mans.am 1.4 644)
+++ mans.am Thu, 22 Feb 2001 20:28:43 +0100 akim (am/g/24_mans.am 1.4 644)
@@ -17,7 +17,7 @@
## 02111-1307, USA.
.PHONY install-man: install-man@SECTION@
-install-man@SECTION@:
+install-man@SECTION@:
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* automake.in: Mying changes.
(handle_tags): Fix a bug uncovered by the previous mying changes:
transform CONFIG into $config, not $xform.
Index: automake.in
--- automake.in Wed, 21 Feb 2001 21:04:28
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* automake.in: Mying changes.
Index: automake.in
--- automake.in Thu, 22 Feb 2001 20:55:47 +0100 akim (am/f/39_automake.i 1.63 755)
+++ automake.in Thu, 22 Feb 2001 21:06:06 +0100 akim (am/f/39_automake.i 1.63 755)
@@ -2480,8
Akim Demaille wrote:
Pavel Roskin [EMAIL PROTECTED] writes:
We probably need a special macro, e.g. AC_REQUIRE_FILE, so that the
macros will be able to indicate what files they need.
This is what Derek and I are working on :) But I doubt 2.50 will be
the good starting point, 2.51 will.
Is there a good reason that the following constructs occasionally appear
in 'configure.in's as created by the test suite?
AM_INIT_AUTOMAKE(nonesuch, nonesuch)
PACKAGE=nonesuch
VERSION=nonesuch
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
Index: ChangeLog
from Akim Demaille [EMAIL PROTECTED]
* automake.in (initialize_per_input): %targets_conditionals is
new.
(read_am_file): When slurping a rule, set the target related
variable, and no variable related variable.
(file_contents): Likewise.
It's only the beginning, but Automake shall not forbid us from having
both a variable INSTALL and a target INSTALL. More is needed, but at
first sight, not too much.
In fact, I've had to finish the job, because the following test was
falling:
cat Makefile.am 'END'
bin_PROGRAMS =
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek Whoops. Excuse me. That works in every case except ($test).
Derek The subshell created by parens breaks things. I guess that
Derek isn't all that robust.
I'm not too concerned about this.
Once we switch fully to using traces, autoconf
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
I imagine we'll have to radically revamp the test suite when we
move to using autoconf's tracing feature. The current test suite
is very dumb and doesn't usually generate a correct configure.in.
Derek I'm working on this so I can test my
"Derek" == Derek R Price [EMAIL PROTECTED] writes:
Derek Is there a good reason that the following constructs
Derek occasionally appear in 'configure.in's as created by the test
Derek suite?
This is almost certainly just a remnant of old times, before
AM_INIT_AUTOMAKE existed.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim -install-man@SECTION@:
Akim +install-man@SECTION@: $(man@SECTION@_MANS) $(man_MANS)
Don't forget to update ChangeLog.
This is ok.
Tom
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim Six, six for them! (I'm not counting those for file handles,
Akim which perl refuses as my, not sure to understand why).
The way file handles work is another reason to dislike Perl. At
least, I've always found them confusing.
Akim *
"Matt" == Matthew R MacIntyre [EMAIL PROTECTED] writes:
Matt Is there an easy way to add a new recursive target to a
Matt top-level Makefile.am?
Nope.
Matt For instance, I have a number of different directories with an
Matt "html" target in them. I'd like to have an easy way to run
Matt
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim In fact, I've had to finish the job, because the following test
Akim was falling:
Akim cat Makefile.am 'END'
Akim bin_PROGRAMS = consud
Akim ## Note next line is target, not variable.
Akim consud_SOURCES: consud.c
Akim
"Kevin" == Kevin Ryde [EMAIL PROTECTED] writes:
Kevin It'd be nice to be able to embed little fragments of perl to do
Kevin things like that, for the "static" case that is. But perhaps
Kevin that idea has come up before.
I've long resisted letting the user extend Makefile.am with Perl code.
I
"Akim" == Akim Demaille [EMAIL PROTECTED] writes:
Akim Yep, by default Automake must not let the users do nonportable
Akim things. I'm sorry about that, but I believe it's a strong
Akim requirement.
I'm finally following up to this -- it was buried in my overly large
automake mailbox.
Akim --
One problem with target/variable separation is that am_line_error
accepts a variable name as its first argument. If they are separate
then some calls to this may become ambiguous. This can probably be
fixed, but it is something to be aware of.
Tom
"Pavel" == Pavel Roskin [EMAIL PROTECTED] writes:
-($from = $2) =~ s/(\W)/\\$1/g;
+($from = $2) =~ s/(\W)/$1/g;
Pavel I don't understrand this. This change will affect the
Pavel traditional rules as well. It should probably be a separate
Pavel patch if it fixes a
"Patrick" == Patrick Guio [EMAIL PROTECTED] writes:
Sorry for the long delay in my reply to this...
Patrick I am not sure if this is to be adressed to libtool or maybe
Patrick automake since the problem might come from depcom...
Could be either.
Patrick Anyway I am trying to build a c++
38 matches
Mail list logo
