Re: AM_CONDITIONAL
On Fri, Sep 21, 2001 at 12:49:00PM -0500, Raja R Harinath wrote: Jens Krüger [EMAIL PROTECTED] writes: /bin/sh: cd: SoNXLakeShore: Datei oder Verzeichnis nicht gefunden Can you translate the message to English? /bin/sh: cd: SoNXLakeShore: File or directory not found Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' ` `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/
Re: help with magically appearing _OBJECTS variable
On Sat, 2001-09-22 at 00:07, Ben Smith wrote: I didn't have this problem until I introduced the conditionals in the Makefile.am. I can't say why this problem is happening since I've not got 1.4p4 installed, and havn't time to try it out. However, having worked on fixing it for 1.5, I can say that the conditional code in the 1.4 branch was severely broken in several ways. There's little prospect of anyone doing the work required to backport the fixes to the 1.4 series. (There's hardly enough developer time on this project to support 1.5) I suspect the most practical solution is to move to 1.5 and fix the slew of other issues that produces. In any case, we would greatly appreciate reports of issues with automake 1.5. Sorry not to have an easy fix. -- Richard
built files in CVS
Hello,
I presume the automake developers track the CVS tree and
frequently build new versions of automake for testing.
Could you let us in on the secret to minimizing the following
annoyance?
The CVS tree includes things like Makefile.in. But this file
is also generated from Makefile.am when I build automake.
The next time I do cvs update, I get a conflict because
of stupid changes like:
steve@riemann{automake-cvs}head Makefile.in
Makefile.in
# Makefile.in generated automatically by automake 1.4i from Makefile.am.
===
# Makefile.in generated automatically by automake 1.5a from Makefile.am.
1.338
I normally end up removing the file, running cvs update again,
then rebuilding. What do the rest of you do?
-Steve
--
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants
Re: Automake 1.5 - depcomp not added to DIST_COMMON
Hi Pavel,
Pavel == Pavel Roskin [EMAIL PROTECTED] writes:
Pavel Hello!
Pavel It looks like I just found a serious bug in Automake 1.5. Perhaps the
Pavel Automake team should follow the example of Autoconf and concentrate on
Pavel making bugfix releases until (almost) everybody is happy.
Pavel The problem is that Automake doesn't add depcomp to DIST_COMMON if
Pavel 1) the sources are in the subdirectory and
Pavel 2) depcomp doesn't already exist in the top-level directory.
depcomp should appear in the DIST_COMMON variable from the
toplevel, unfortunately its existence starts only when
subdir/Makefile.am is processed, after the toplevel Makefile.in
has been output.
On the next automake run, depcomp is already there so it is
added to DIST_COMMON automatically.
So what about rerunning automake automatically (well, actually just
reprocessing the Makefiles) when such case is detected? The
patch below does that. Yeah, this sounds as ugly as processing
a LaTeX file in loop until all references are resolved :(
[...]
2001-09-22 Alexandre Duret-Lutz [EMAIL PROTECTED]
Fix for distcommon2.test:
* automake.in (automake_needs_to_reprocess_all_files): New
variable.
(main): Process all Makefiles a second time if
$automake_needs_to_reprocess_all_files is set.
(maybe_push_required_file): Return 1 or 0 whether the file is
pushed or not.
(require_file_internal): Set $automake_needs_to_reprocess_all_files
if an added file can't be pushed.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1173
diff -u -r1.1173 automake.in
--- automake.in 2001/08/28 03:53:10 1.1173
+++ automake.in 2001/09/22 18:31:50
@@ -486,6 +486,11 @@
'install-man' = 1,
);
+# This is set to 1 when Automake needs to be run again.
+# (For instance, this happens when an auxiliary file such as
+# depcomp is added after the toplevel Makefile.in -- which
+# should distribute depcomp -- has been generated.)
+my $automake_needs_to_reprocess_all_files = 0;
@@ -1010,21 +1015,36 @@
die $me: no `Makefile.am' found or specified\n
if ! @input_files;
-# Now do all the work on each file.
-# This guy must be local otherwise it's private to the loop.
-use vars '$am_file';
-local $am_file;
-foreach $am_file (@input_files)
+my $automake_has_run = 0;
+
+do
{
-if (! -f ($am_file . '.am'))
+if ($automake_has_run)
{
- am_error (` . $am_file . .am' does not exist);
+ print $me: processing Makefiles another time to fix them up.\n;
+ prog_error (running more than two times should never be needed.)
+ if $automake_has_run = 2;
}
-else
+$automake_needs_to_reprocess_all_files = 0;
+
+# Now do all the work on each file.
+# This guy must be local otherwise it's private to the loop.
+use vars '$am_file';
+local $am_file;
+foreach $am_file (@input_files)
{
- generate_makefile ($output_files{$am_file}, $am_file);
+ if (! -f ($am_file . '.am'))
+ {
+ am_error (` . $am_file . .am' does not exist);
+ }
+ else
+ {
+ generate_makefile ($output_files{$am_file}, $am_file);
+ }
}
+++$automake_has_run;
}
+while ($automake_needs_to_reprocess_all_files);
exit $exit_status;
@@ -7657,6 +7677,7 @@
if ($dir eq $relative_dir)
{
push_dist_common ($file);
+ return 1;
}
elsif ($relative_dir eq '.' ! is_make_dir ($dir))
{
@@ -7664,7 +7685,9 @@
# subdir which does not have a Makefile, then we distribute it
# here.
push_dist_common ($fullfile);
+ return 1;
}
+return 0;
}
@@ -7787,8 +7810,24 @@
}
}
- maybe_push_required_file (dirname ($errfile),
- $file, $errfile);
+ if (! maybe_push_required_file (dirname ($errfile),
+$file, $errfile))
+ {
+ if (! $found_it)
+ {
+ # We have added the file but could not push it
+ # into DIST_COMMON (probably because this is
+ # an auxiliary file and we are not processing
+ # the top level Makefile). This is unfortunate,
+ # since it means we are using a file which is not
+ # distributed!
+
+ # Get Automake to be run again: on the second
+ # run the file will be found, and pushed into
+ # the toplevel DIST_COMMON automatically.
+ $automake_needs_to_reprocess_all_files
Re: help with magically appearing _OBJECTS variable
Richard, thank you for the reply. Automake 1.5 solves the problem, more details below. On 22 Sep 2001, Richard Boulton wrote: On Sat, 2001-09-22 at 00:07, Ben Smith wrote: I didn't have this problem until I introduced the conditionals in the Makefile.am. I can't say why this problem is happening since I've not got 1.4p4 installed, and havn't time to try it out. However, having worked on fixing it for 1.5, I can say that the conditional code in the 1.4 branch was severely broken in several ways. There's little prospect of anyone doing the work required to backport the fixes to the 1.4 series. Okay, good to know. (There's hardly enough developer time on this project to support 1.5) I suspect the most practical solution is to move to 1.5 and fix the slew of other issues that produces. Honestly, I didn't look too in-depth at those issues. I just saw that I got several warnings about macros being undefined and probably some other things and decided that I'd rather see what people on the mailing list thought. In any case, we would greatly appreciate reports of issues with automake 1.5. I resolved the issues, they were easy enough to fix. The first bit of it was warnings when am 1.5 read the aclocal.m4 that had been added to by automake1.4-p4 and 1.4-p5, not surprising it didn't like that. The second was adding my libtool.m4 to a place where automake would be happy with it. My only real resistance to using 1.5 was it's not yet installed via debian unstable, and I wasn't sure if others would need am 1.5 to build my software. They don't. My conditionals in my Makefile.am work just fine with automake 1.5. I have tried it on machines with SDL and without, everything seems cool. Sorry not to have an easy fix. -- Richard Well, it wasn't very hard, either. Another option for me may have been to put all the optional stuff in a separate directory and add that directory via @extra tests@ to one of the Makefile.am files. I didn't try this because I'm happy with the current resolution. Thank you, and others that work on this tool. I really don't want to deal with the multi-platform compilation nightmare. I appreciate all the work you guys do, it makes it easier for me to reach a lot of people with my projects. -b
Re: Automake 1.5 - depcomp not added to DIST_COMMON
Hi,
Alexandre Duret-Lutz [EMAIL PROTECTED] writes:
[snip]
+$automake_needs_to_reprocess_all_files = 0;
+
+# Now do all the work on each file.
+# This guy must be local otherwise it's private to the loop.
+use vars '$am_file';
+local $am_file;
+foreach $am_file (@input_files)
{
- generate_makefile ($output_files{$am_file}, $am_file);
+ if (! -f ($am_file . '.am'))
+ {
+ am_error (` . $am_file . .am' does not exist);
+ }
+ else
+ {
+ generate_makefile ($output_files{$am_file}, $am_file);
+ }
}
+++$automake_has_run;
}
+while ($automake_needs_to_reprocess_all_files);
This doesn't look like it'll work with, say
automake --add-missing src/Makefile
This won't add 'depcomp' to DIST_COMMON in the top Makefile.in.
- Hari
--
Raja R Harinath -- [EMAIL PROTECTED]
When all else fails, read the instructions. -- Cahn's Axiom
Our policy is, when in doubt, do the right thing. -- Roy L Ash
Re: built files in CVS
Steve M. Robbins wrote:
Hello,
I presume the automake developers track the CVS tree and
frequently build new versions of automake for testing.
Could you let us in on the secret to minimizing the following
annoyance?
The CVS tree includes things like Makefile.in. But this file
is also generated from Makefile.am when I build automake.
The next time I do cvs update, I get a conflict because
of stupid changes like:
steve@riemann{automake-cvs}head Makefile.in
Makefile.in
# Makefile.in generated automatically by automake 1.4i from Makefile.am.
===
# Makefile.in generated automatically by automake 1.5a from Makefile.am.
1.338
I normally end up removing the file, running cvs update again,
then rebuilding. What do the rest of you do?
-Steve
You shouldn't see this problem unless someone rebuilt the `Makefile.in's
with a new version of Automake and checked them in since the last time you
checked out. One of the simple ways to avoid this is to have the
developers on your project agree and standardize on the same version of
Automake.
I don't know of another workaround for this other than the one you mention.
With CVS, we have a toplevel script, `noautomake.sh' which can be run to
avoid rebuilding automake and autoconf files after a fresh update or
checkout. You do have to be careful to avoid running this script after you
have changed configuration files, but it's convenient when you are
attempting to support people who might be using a heterogeneous set of
Automake and Autoconf versions, sometimes build the source from CVS, and
don't usually change the Automake/Autoconf config files. I think I've
heard of similar scripts being used on other projects, but I couldn't name
any. Copy of script attached.
Derek
noautomake.sh
Re: Automake 1.5 - depcomp not added to DIST_COMMON
- Original Message - From: Raja R Harinath [EMAIL PROTECTED] This doesn't look like it'll work with, say automake --add-missing src/Makefile This won't add 'depcomp' to DIST_COMMON in the top Makefile.in. You cannot use automake --add-missing src/Makefile until a straight automake --add-missing has been called - because automake doesn't know about src until then. So there should be no issue (the first automake invocation should add depcomp). Rob
