Re: [PATCH 4/4] New automake command line option `--silent-rules'.
Hi, Jan Engelhardt jeng...@medozas.de writes: On Monday 2009-03-09 15:57, Ralf Corsepius wrote: For this patch, I'm unsure if we should even add it at all. FWIW: I am opposed to it. All this silencing stuff does is to add further potential sources of errors. Which ones, please? Those yet to be discovered. Oh what great prejudice. Do you actually know what exactly this patch series silences, or are you just guessing? If I understand the context, Ralf is objecting to the --silent-rules command-line option which makes it easy for distribution vendors to enable silent builds across the board by overriding $AUTOMAKE. I agree with the sentiment (somewhat hinted-to by Ralf Wildenhues in his commit message): this feature should be an opt-in by the package maintainer. He should take the responsibility for making the trade-off: easier-to-read silent builds vs. potential bugs due to hiding of information. - Hari
Re: blank line following trailing backslash
Hi, Andreas roe...@users.sf.net writes: I just had an ingenious idea to limit conflicts in versioning systems. When you specify a list of files for a rule you put every file in a line like this. fileA.c \ fileB.c \ fileC.c One slightly ugly-looking approach I've seen is EMPTY = foo_SOURCES = \ fileA.c \ fileB.c \ fileC.c \ $(EMPTY) - Hari
Re: automake less verbose (iter 3)
Hi, Jan Engelhardt jeng...@medozas.de writes: On Monday 2008-12-22 21:36, Ralf Wildenhues wrote: On Monday 2008-12-15 21:19, William Pursell wrote: The make info pages mention that $? expands to “all the prerequisites that are newer than the target”, and that sounds like there could be more than just the .c file. I just noticed that LD should have used $^. Replying to myself - no it should not :p gmake's $^ is not supported by BSD make. And BSD make's $ is not supported by gmake. ( :-/ )^2 And non-GNU make support $ only in inference rules and not elsewhere. In that case, removing V=1 again is probably the best solution. (Leaving only V=0 and V=infinity) Not necessarily. We could document that V=1 is supported, as in expected to generate clean output, only on GNU make. On other makes, '$' probably expands to the empty string, causing only mildly strange looking output otherwise equivalent to V=0. - Hari
Re: best practice for injecting include dir across a project
Hi, Monty Taylor [EMAIL PROTECTED] writes: I've got a project that has 24 Makefile.am files. At the top of all of them at the moment, I've got: AM_CPPFLAGS = -I$(top_builddir)/include -I$(top_srcdir)/include [snip] PS. Yes...I know the -I$(top_builddir)/include is ridiculous... I inherited that and just haven't gotten rid of it yet... but the fundamental question of how do I add one or more include paths globally from a top level in a sane manner still holds... Since your main question got answered... What's wrong with -I$(top_builddir)/include? It's most definitely not redundant. Of course it can be superfluous if you don't have any generated header files in the build tree. But, why ridiculous? - Hari
Re: [RFD] Support Mono/.NET
Hi, Ralf Wildenhues Ralf.Wildenhues at gmx.de writes: * Raja R Harinath wrote on Thu, Jun 28, 2007 at 03:13:15PM CEST: I'm attaching a series of patches adding support for Mono/.NET/ECMA-335 (also called the CLI, common language infrastructure). I'm working on documenting the support, but the testcases show example usage. Thank you very much for your patches, esp. all the nice test examples. Thanks (and sorry about the multiple e-mails. I had a lot of trouble getting e-mail out from my laptop, and ended up sending multiple copies). I have completed more of the work, and you can find some more information at: http://idea.opensuse.org/content/ideas/better-automake-support-for-mono I've a more complete patchset available at: http://blog.hurrynot.org/mono-in-automake/patches and a sample tarball at: http://blog.hurrynot.org/mono-in-automake/test-1.0.tar.gz (I don't want to e-mail the new patches since I had so much trouble last time). I'm a complete newbie when it comes to CLI, so is there a website or manuals for me to get a jump start on things (notation, compilers and options, file types)? Hmm... Not in one place, unfortunately :-) There is some information on Microsoft's .NET site -- the following may be a starting point http://msdn2.microsoft.com/en-us/library/78f4aasd(VS.80).aspx There is probably also some information on mono-project.com http://mono-project.com/Monkeyguide http://mono-project.com/Introduction_to_developing_with_Mono Is the intention to support both the Mono as well as the w32 suite Yes. (are there more)? Yes. There's the DotGNU/Portable.NET project. I'm not familiar with this project, but expect that the specifics of invocation of compilers, the extensions of output files, etc., are the same. On which systems (all unixoids plus w32)? However, the current patch only works with Mono (either on unixoid, or on w32). Microsoft's compilers don't like seeing '/' in filenames, and I thought it would be too much of a diversion trying ot detect and convert '/'es to '\'es. That's a patch for another day :-) Those extensions really are .exe and .dll everywhere, not only on w32? Yes. CLI binaries are akin to Java .jar files, and contain a lot of similar metadata. The code is not native code, but a bytecode called the CIL (common intermediate language). However, they are named with .exe and .dll since they contain enough of the MZ/PE headers to invoke the .NET Jit on w32. On Unixoid machines, they are explicitly invoked with the Mono jit: mono foo.exe - Hari
[RFD] Support Mono/.NET
Hi, I'm attaching a series of patches adding support for Mono/.NET/ECMA-335 (also called the CLI, common language infrastructure). I'm working on documenting the support, but the testcases show example usage. - Hari
[PATCH 1/4] Add basic support for Mono/.NET
* automake.in (register_language): Add 'cli'.
(handle_cli, handle_cli_assembly, lang_cli_rewrite): New.
(generate_makefile): Call 'handle_cli'.
* lib/am/Makefile.am (dist_am_DATA): Update.
* lib/am/cli.am, lib/am/cli-assembly.am: New.
* tests/cli1.test: Simple test for Mono/.NET support.
* tests/Makefile.am (TESTS): Update.
---
ChangeLog | 11
automake.in| 127
lib/am/Makefile.am |2 +
lib/am/cli-assembly.am | 22
lib/am/cli.am | 25 +
tests/Makefile.am |1 +
tests/cli1.test| 40 +++
7 files changed, 228 insertions(+), 0 deletions(-)
create mode 100644 lib/am/cli-assembly.am
create mode 100644 lib/am/cli.am
create mode 100755 tests/cli1.test
diff --git a/ChangeLog b/ChangeLog
index 0730b31..b246d80 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2007-06-27 Raja R Harinath [EMAIL PROTECTED]
+
+ Add basic support for Mono/.NET
+ * automake.in (register_language): Add 'cli'.
+ (handle_cli, handle_cli_assembly, lang_cli_rewrite): New.
+ (generate_makefile): Call 'handle_cli'.
+ * lib/am/Makefile.am (dist_am_DATA): Update.
+ * lib/am/cli.am, lib/am/cli-assembly.am: New.
+ * tests/cli1.test: Simple test for Mono/.NET support.
+ * tests/Makefile.am (TESTS): Update.
+
2007-06-23 Paul Eggert [EMAIL PROTECTED]
Ralf Wildenhues [EMAIL PROTECTED]
diff --git a/automake.in b/automake.in
index 083b6fa..de33217 100755
--- a/automake.in
+++ b/automake.in
@@ -983,6 +983,16 @@ register_language ('name' = 'java',
'pure' = 1,
'extensions' = ['.java', '.class', '.zip', '.jar']);
+# CLI - C#, VB
+register_language ('name' = 'cli',
+ 'Name' = 'Common Language Infrastructure (C# or VB)',
+ 'extensions' = ['.cs', '.vb'],
+ # No output.
+ 'output_extensions' = sub { return () },
+ # Nothing to do.
+ '_finish' = sub { });
+
+
# Error reporting functions.
@@ -4673,6 +4683,114 @@ sub handle_java
push (@all, 'class' . $dir . '.stamp');
}
+sub handle_cli_assembly ($$$%)
+{
+ my ($one_file, $unxformed, $where, %transform) = @_;
+ my $compiler = '';
+ my @cmdsrcs = ();
+ my $seen_extn = 0;
+
+ foreach my $prefix ('', 'EXTRA_', 'dist_', 'nodist_',
+ 'dist_EXTRA_', 'nodist_EXTRA_')
+{
+ my $varname = $prefix . $one_file . _SOURCES;
+ my $var = var $varname;
+ next unless $var;
+ my $xpfx = ($prefix eq '') ? 'am_' : $prefix;
+ my $outvarname = $xpfx . $one_file . _CMDSRCS;
+ my $nodist = ($prefix =~ /^nodist_/);
+ my $nodefine = ($prefix =~ /EXTRA_/);
+
+ push @cmdsrcs, \$($outvarname);
+
+ push @sources, \$($varname);
+ push @dist_sources, shadow_unconditionally ($varname, $where)
+ unless (option ('no-dist') || $nodist);
+
+ $output_rules .= $unxformed: \$($varname)\n;
+
+ $var-transform_variable_recursively
+ ($outvarname, 'am__cli', $nodefine, $where,
+sub {
+ my ($subvar, $val, $cond, $full_cond) = @_;
+ return ()
+unless $val =~ /($KNOWN_EXTENSIONS_PATTERN)$/;
+ my $extn = $1;
+
+ if ($seen_extn)
+{
+ msg_var 'error', $varname, multi-language assemblies not
supported: $seen_extn $extn
+unless $extn eq $seen_extn;
+}
+ else
+{
+ $seen_extn = $extn;
+}
+
+ if (rule $val)
+{
+ return $val if $nodist;
+ msg_var 'error', $subvar, `$val' has a rule to build it, but is
also distributed;
+}
+ return '$(srcdir)/' . $val;
+});
+}
+
+ msg 'error', $where, `$unxformed' doesn't have any source defined
+unless scalar @cmdsrcs;
+
+ define_pretty_variable ($one_file . '_CMDSRCS', TRUE, $where, sort @cmdsrcs);
+
+ my $lang = uc substr $seen_extn, 1;
+ my $dirstamp = require_build_directory_maybe ($unxformed);
+ my $progflags = ${one_file}_${lang}FLAGS;
+
+ require_variables ($unxformed, Seen CLI source file with extension
$seen_extn, TRUE, $lang . 'C');
+ define_variable ($progflags, \$(AM_${lang}FLAGS), INTERNAL)
+unless var $progflags;
+
+ $output_rules .=
+file_contents ('cli-assembly', $where,
+ %transform,
+ ASSEMBLY = $unxformed,
+ XASSEMBLY = $one_file,
+ LANG = $lang,
+ DIRSTAMP = $dirstamp);
+}
+
+# Handle Mono/.NET
+sub handle_cli
+{
+ my %targets = ( EXE = 'exe', WINEXE = 'winexe', DLL = 'library', MODULE
= 'module' );
+ my %outextns = ( EXE = '.exe', WINEXE = '.exe', DLL = '.dll', MODULE =
'.netmodule' );
+ foreach my $target (keys %targets)
+{
+ my
[PATCH 3/4] Add support for resources
* automake.in (handle_cli_assembly_sources): Rename from handle_cli_assembly.
(handle_cli_assembly_resources): New. Add support for handling resources.
(handle_cli_assembly): Call both the previous methods.
(cli_need_resgen): New.
(handle_cli): Use it to emit RESGEN suffix rules, if necessary.
* lib/am/cli.am (clean-%DIR%%PRIMARY%): Remove *.resources.
* tests/cli3.test: New.
* tests/Makefile.am (TESTS): Update.
---
ChangeLog | 12 ++
automake.in | 97 +++-
lib/am/cli.am |1 +
tests/Makefile.am |1 +
tests/cli3.test | 46 +
5 files changed, 155 insertions(+), 2 deletions(-)
create mode 100755 tests/cli3.test
diff --git a/ChangeLog b/ChangeLog
index ec49428..2e75139 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,17 @@
2007-06-27 Raja R Harinath [EMAIL PROTECTED]
+ Add support for resources
+ * automake.in (handle_cli_assembly_sources): Rename from
+ handle_cli_assembly.
+ (handle_cli_assembly_resources): New. Add support for handling
+ resources.
+ (handle_cli_assembly): Call both the previous methods.
+ (cli_need_resgen): New.
+ (handle_cli): Use it to emit RESGEN suffix rules, if necessary.
+ * lib/am/cli.am (clean-%DIR%%PRIMARY%): Remove *.resources.
+ * tests/cli3.test: New.
+ * tests/Makefile.am (TESTS): Update.
+
Compute dependencies from assembly references
* automake.in (handle_cli_assembly): Return true on success.
(handle_cli_assembly_references): New.
diff --git a/automake.in b/automake.in
index 9bf8b43..c2ab593 100755
--- a/automake.in
+++ b/automake.in
@@ -4683,7 +4683,7 @@ sub handle_java
push (@all, 'class' . $dir . '.stamp');
}
-sub handle_cli_assembly ($$$%)
+sub handle_cli_assembly_sources ($$$%)
{
my ($one_file, $unxformed, $where, %transform) = @_;
my @cmdsrcs = ();
@@ -4700,7 +4700,8 @@ sub handle_cli_assembly ($$$%)
my $nodist = ($prefix =~ /^nodist_/);
my $nodefine = ($prefix =~ /EXTRA_/);
- push @cmdsrcs, \$($outvarname);
+ push @cmdsrcs, \$($outvarname)
+ unless $nodefine;
push @sources, \$($varname);
push @dist_sources, shadow_unconditionally ($varname, $where)
@@ -4762,6 +4763,78 @@ sub handle_cli_assembly ($$$%)
return 1;
}
+my $cli_need_resgen;
+
+sub handle_cli_assembly_resources ($$$%)
+{
+ my ($one_file, $unxformed, $where, %transform) = @_;
+ my @cmdrsrcs = ();
+
+ foreach my $prefix ('', 'EXTRA_', 'dist_', 'nodist_',
+ 'dist_EXTRA_', 'nodist_EXTRA_')
+{
+ my $varname = $prefix . $one_file . _RESOURCES;
+ my $var = var $varname;
+ next unless $var;
+ my $xpfx = ($prefix eq '') ? 'am_' : $prefix;
+ my $cmdrsrc = $xpfx . $one_file . _CMDRSRCS;
+ my $deprsrc = $xpfx . $one_file . _DEPRSRCS;
+ my $nodist = ($prefix =~ /^nodist_/);
+ my $nodefine = ($prefix =~ /EXTRA_/);
+
+ my @distrsrcs = uniq sort map { s/^(.*),([^,]*)$/$1/; $_ }
$var-value_as_list_recursive;
+ push_dist_common (@distrsrcs)
+ unless (option ('no-dist') || $nodist);
+
+ $var-transform_variable_recursively
+ ($deprsrc, 'am__cli', $nodefine, $where,
+sub {
+ my ($subvar, $val, $cond, $full_cond) = @_;
+ $val =~ s/^(.*),([^,]*)$/$1/;
+ $val =~ s/\.(resx|txt|po)$/.resources/;
+ return $val;
+});
+
+ $output_rules .= $unxformed: \$($deprsrc)\n
+ unless $nodefine;
+
+ push @cmdrsrcs, \$($cmdrsrc);
+
+ $var-transform_variable_recursively
+ ($cmdrsrc, 'am__cli', $nodefine, $where,
+sub {
+ my ($subvar, $val, $cond, $full_cond) = @_;
+ my $rsrc_name = ();
+ my $nosrcdir = $nodist;
+ if ($val =~ /^(.*),([^,]*)$/)
+{
+ $val = $1;
+ $rsrc_name = $2;
+}
+ if ($val =~ /\.(resx|txt|po)$/)
+{
+ $val =~ s/\.(resx|txt|po)$/.resources/;
+ $nosrcdir = 1;
+ $cli_need_resgen = $where;
+}
+ my $retval = -resource:;
+ $retval .= '$(srcdir)/'
+unless $nosrcdir;
+ $retval .= $val;
+ $retval .= ,$rsrc_name
+if $rsrc_name;
+ return $retval;
+});
+}
+
+ return 1
+if scalar @cmdrsrcs == 0;
+
+ define_pretty_variable ($one_file . '_CMDRSRCS', TRUE, $where, sort
@cmdrsrcs);
+
+ return 1;
+}
+
sub handle_cli_assembly_references(\%)
{
my ($known_assemblies) = @_;
@@ -4807,6 +4880,14 @@ sub handle_cli_assembly_references(\%)
}
}
+sub handle_cli_assembly ($$$%)
+{
+ my ($one_file, $unxformed, $where, %transform) = @_;
+ my $sources_ok = handle_cli_assembly_sources $one_file, $unxformed, $where,
%transform;
+ my $resources_ok = handle_cli_assembly_resources $one_file, $unxformed,
$where, %transform;
+ return $sources_ok
[PATCH 4/4] Add a convenience autoconf macro (AM_PROG_CLI) to help with matters.
* automake.in (register_language): Add Nemerle (.n) and Boo (.boo)
as languages supported by the CLI infrastructure.
(handle_cli_assembly_sources): Handle single-char extensions --
compiler variable ends in 'CC' rather than 'C'.
* lib/am/cli-assembly.am (%ASSEMBLY%): Use %LANGCC% instead of
%LANG%C for the name of the compiler variable.
* m4/cli.m4: New.
* m4/Makefile.am (dist_m4data_DATA): Add cli.m4.
* tests/cli4.test, tests/clim4-1.test, tests/clim4-2.test: New.
* tests/clim4-3.test, tests/clim4-4.test: New.
* tests/Makefile.am (TESTS): Update.
---
ChangeLog | 15 +++
automake.in| 10 ++
lib/am/cli-assembly.am |2 +-
m4/Makefile.am |1 +
m4/cli.m4 | 38 ++
tests/Makefile.am |5 +
tests/cli4.test| 37 +
tests/clim4-1.test | 40
tests/clim4-2.test | 40
tests/clim4-3.test | 40
tests/clim4-4.test | 41 +
11 files changed, 264 insertions(+), 5 deletions(-)
create mode 100644 m4/cli.m4
create mode 100755 tests/cli4.test
create mode 100755 tests/clim4-1.test
create mode 100755 tests/clim4-2.test
create mode 100755 tests/clim4-3.test
create mode 100755 tests/clim4-4.test
diff --git a/ChangeLog b/ChangeLog
index 2e75139..07e7edb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,18 @@
+2007-06-28 Raja R Harinath [EMAIL PROTECTED]
+
+ Add a convenience autoconf macro (AM_PROG_CLI) to help with matters.
+ * automake.in (register_language): Add Nemerle (.n) and Boo (.boo)
+ as languages supported by the CLI infrastructure.
+ (handle_cli_assembly_sources): Handle single-char extensions --
+ compiler variable ends in 'CC' rather than 'C'.
+ * lib/am/cli-assembly.am (%ASSEMBLY%): Use %LANGCC% instead of
+ %LANG%C for the name of the compiler variable.
+ * m4/cli.m4: New.
+ * m4/Makefile.am (dist_m4data_DATA): Add cli.m4.
+ * tests/cli4.test, tests/clim4-1.test, tests/clim4-2.test: New.
+ * tests/clim4-3.test, tests/clim4-4.test: New.
+ * tests/Makefile.am (TESTS): Update.
+
2007-06-27 Raja R Harinath [EMAIL PROTECTED]
Add support for resources
diff --git a/automake.in b/automake.in
index c2ab593..aa5709a 100755
--- a/automake.in
+++ b/automake.in
@@ -983,10 +983,10 @@ register_language ('name' = 'java',
'pure' = 1,
'extensions' = ['.java', '.class', '.zip', '.jar']);
-# CLI - C#, VB
+# CLI - C#, VB, Nemerle, Boo
register_language ('name' = 'cli',
- 'Name' = 'Common Language Infrastructure (C# or VB)',
- 'extensions' = ['.cs', '.vb'],
+ 'Name' = 'Common Language Infrastructure (C#, VB, Nemerle,
Boo)',
+ 'extensions' = ['.cs', '.vb', '.n', '.boo'],
# No output.
'output_extensions' = sub { return () },
# Nothing to do.
@@ -4747,8 +4747,9 @@ sub handle_cli_assembly_sources ($$$%)
my $lang = uc substr $seen_extn, 1;
my $dirstamp = require_build_directory_maybe ($unxformed);
my $progflags = ${one_file}_${lang}FLAGS;
+ my $langcc = (length $lang == 1) ? ${lang}CC : ${lang}C;
- require_variables ($unxformed, Seen CLI source file with extension
$seen_extn, TRUE, $lang . 'C');
+ require_variables ($unxformed, Seen CLI source file with extension
$seen_extn, TRUE, $langcc);
define_variable ($progflags, \$(AM_${lang}FLAGS), INTERNAL)
unless var $progflags;
@@ -4758,6 +4759,7 @@ sub handle_cli_assembly_sources ($$$%)
ASSEMBLY = $unxformed,
XASSEMBLY = $one_file,
LANG = $lang,
+ LANGCC = $langcc,
DIRSTAMP = $dirstamp);
return 1;
diff --git a/lib/am/cli-assembly.am b/lib/am/cli-assembly.am
index f85710c..bf5ed42 100644
--- a/lib/am/cli-assembly.am
+++ b/lib/am/cli-assembly.am
@@ -18,5 +18,5 @@
## 02110-1301, USA.
%ASSEMBLY%: $(%XASSEMBLY%_DEPENDENCIES) %DIRSTAMP%
@rm -f %ASSEMBLY%
- $(%LANG%C) $(%XASSEMBLY%_%LANG%FLAGS) $(%LANG%FLAGS) -out:$@
-target:%TARGET% \
+ $(%LANGCC%) $(%XASSEMBLY%_%LANG%FLAGS) $(%LANG%FLAGS) -out:$@
-target:%TARGET% \
$(%XASSEMBLY%_CMDSRCS) $(%XASSEMBLY%_CMDRSRCS)
$(%XASSEMBLY%_REFERENCES)
diff --git a/m4/Makefile.am b/m4/Makefile.am
index 13d4243..a25ed3b 100644
--- a/m4/Makefile.am
+++ b/m4/Makefile.am
@@ -27,6 +27,7 @@ $(top_srcdir)/m4/amversion.m4 \
as.m4 \
auxdir.m4 \
ccstdc.m4 \
+cli.m4 \
cond.m4 \
depend.m4 \
depout.m4 \
diff --git a/m4/cli.m4 b/m4/cli.m4
new file mode 100644
index 000..a0c9b92
--- /dev/null
+++ b/m4/cli.m4
@@ -0,0 +1,38 @@
+# Check for CLI compilers. -*- Autoconf
Automake support for Mono
Hi, I got a chance to work on automake after 4 years :-) As part of the Novell HackWeek, I'm working on a set of patches to add native support for Mono/.NET assemblies to automake. I have a promising start, and would like to get some comments. I'll try to post the in-work patches onto the '-patches' list soon. - Hari
Re: superfluous test in AC_CHECK_HEADERS?
Hi, Frederik Fouvry [EMAIL PROTECTED] writes: I'm using AC_CHECK_HEADERS([ecl.h]) in configure.ac, and that gives the following in the log file (autoconf 2.57): configure:5067: checking ecl.h usability configure:5080: gcc -c -g -O2 -I/proj/contrib/lkb/latest/include -I/proj/contrib/lib/ecl/h conftest.c 5 configure:5083: $? = 0 configure:5086: test -s conftest.o configure:5089: $? = 0 configure:5099: result: yes configure:5103: checking ecl.h presence configure:5114: gcc -E -I/proj/contrib/lkb/latest/include -I/proj/contrib/lib/ecl/h conftest.c configure:5120: $? = 0 configure:5139: result: yes configure:5175: checking for ecl.h configure:5182: result: yes It first tests whether it can compile with the header file, and then tests if the file exists or not. Is the second test not subsumed by the first one (if that one is successful)? The first test uses $CFLAGS and $CPPFLAGS, while the second only uses $CPPFLAGS. If you have some -I and -D in your $CFLAGS, the results will differ. (I'm not justifying the double check. I'm just saying that the second is not entirely redundant :-) - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: how to change the behaviour of make check?
Hi, Thien-Thi Nguyen [EMAIL PROTECTED] writes: Date: Wed, 17 Sep 2003 14:07:17 -0600 (MDT) From: Ireneusz SZCZESNIAK [EMAIL PROTECTED] Yeah! But still I want the output of make check to be clean. When a test fails, then I expect to see: FAIL: test.sh. in this case the only thing i can suggest is to post-process the Makefile to change the check-TESTS target near the end to not check for failures. you might offend purists, but anyway, this can be done like so: ./configure cp Makefile TMP grep -v ^[ ]*test ...failed. -eq 0 TMP Makefile rm TMP make That seems a roundabout way to do it. Just copy the check-TESTS rule into your Makefile.am file, and automake won't generate its internal rule. You can customize your local copy of check-TESTS to your heart's content. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
Hi,
Andrew Suffield [EMAIL PROTECTED] writes:
On Mon, Jul 28, 2003 at 05:55:15PM -0500, Raja R Harinath wrote:
Andrew Suffield [EMAIL PROTECTED] writes:
[snip autoreconf/autopoint/AM_GNU_GETTEXT([external]) dicussion]
All that does is stop including a complete copy of libintl in your
source tree. autopoint still wants to add a few dozen files. The best
solution is to not run autopoint at all, since it doesn't do anything
useful if you don't want to include a copy of gettext in your
distributed tarballs.
But, you asked for with AM_GNU_GETTEXT.
AFAIR, the files are all limited to the po/ directory, and they're all
used either by AM_GNU_GETTEXT or po/Makefile.in.in.
No, there are about half a dozen files in po/ which aren't needed, and
then there's all the m4 macros.
Sorry to keep harping on this. I'm trying to figure out if we should
report this as a bug to the gettext maintainer or not.
Having m4 macros in the source tree is better IMHO. You have better
control over the sources that you're building. Also, there's a
matched set of m4/{gettext,po,...}.m4 and po/Makefile.in.in -- which
is good. Also, with 'aclocal' 1.8, this is pretty cheap, since the
they'll just put
m4_include([m4/gettext.m4])
m4_include([m4/po.m4])
etc.
into aclocal.m4. There's no need for m4/Makefile.am, since they're
automatically distributed, and all that jazz. The whole thing is now
very lightweight.
I do agree that using
AM_GNU_GETTEXT([external])
shouldn't pull in m4 macros that are used only for building in an
intl/ subtree. That'd need further changes to introduce something like
AM_EXTERNAL_GNU_GETTEXT
that we could use instead.
As to the files in po/. Apart from po/Makefile.in.in, I see the
following:
Rules-quot
boldquot.sed
[EMAIL PROTECTED]
[EMAIL PROTECTED]
insert-header.sin
quot.sed
remove-potcdate.sin
All the script fragments are used by Rules-quot. That file isn't
directly referred to by Makefile.in.in. However, Rules-quot is
appended to the generated po/Makefile by m4/po.m4.
for f in $ac_given_srcdir/$ac_dir/Rules-*; do
if test -f $f; then
case $f in
*.orig | *.bak | *~) ;;
*) cat $f $ac_dir/Makefile ;;
esac
fi
done
As to the utility of this whole set of files: I can't judge. If I'm
not mistaken, they seem to be for the use of the translation team to
automatically generate simple variants of the messages that are more
suitable to an 'en_US' locale than those of the 'C' locale -- assuming
you use ISO8859-1 rather than 7-bit ASCII.
- Hari
--
Raja R Harinath -- [EMAIL PROTECTED]
Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
Hi, Andrew Suffield [EMAIL PROTECTED] writes: On Mon, Jul 28, 2003 at 11:39:48PM +0200, Alexandre Duret-Lutz wrote: Andrew == Andrew Suffield [EMAIL PROTECTED] writes: [...] snip This whole script (including its last part) can be replaced by autoreconf -im (I'd use -vfim, though.) autoreconf has a habit of doing silly things like running autopoint, which then cheerfully adds a bunch of gunk to the source tree which you didn't want. I've never seen it actually do what I wanted, and frankly, it's far too complicated for what should be a trivial script. It does that only when you ask for 'gettext'. On most modern machines, esp. on Debian, you should replace AM_GNU_GETTEXT with AM_GNU_GETTEXT_VERSION([0.12.1]) # or appropriate version AM_GNU_GETTEXT([external]) and thinks will be peachier. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
Andrew Suffield [EMAIL PROTECTED] writes: On Mon, Jul 28, 2003 at 05:33:43PM -0500, Raja R Harinath wrote: Andrew Suffield [EMAIL PROTECTED] writes: autoreconf has a habit of doing silly things like running autopoint, which then cheerfully adds a bunch of gunk to the source tree which you didn't want. I've never seen it actually do what I wanted, and frankly, it's far too complicated for what should be a trivial script. It does that only when you ask for 'gettext'. On most modern machines, esp. on Debian, you should replace AM_GNU_GETTEXT with AM_GNU_GETTEXT_VERSION([0.12.1]) # or appropriate version AM_GNU_GETTEXT([external]) and thinks will be peachier. All that does is stop including a complete copy of libintl in your source tree. autopoint still wants to add a few dozen files. The best solution is to not run autopoint at all, since it doesn't do anything useful if you don't want to include a copy of gettext in your distributed tarballs. But, you asked for with AM_GNU_GETTEXT. AFAIR, the files are all limited to the po/ directory, and they're all used either by AM_GNU_GETTEXT or po/Makefile.in.in. The only issue with upgrading from previous versions of po/Makefile.in.in is that you have to create po/Makevars, which you can do once and for all with sed 's,^MSGID_BUGS_ADDRESS =, [EMAIL PROTECTED],' po/Makevars.template po/Makevars You can check in po/Makevars into the CVS repository. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: Filenames containing blanks
Hi, Alexandre Duret-Lutz [EMAIL PROTECTED] writes: gd == Guido Draheim [EMAIL PROTECTED] writes: gd Alexandre Duret-Lutz wrote: Ralf == Ralf Corsepius [EMAIL PROTECTED] writes: Ralf Hi, Ralf Simple question: Does automake support filenames containing blanks? I guess nobody really bothered because Make itself uses blanks as filename separators. '\ ' seems to be a GNU extension, does anybody knows of another implementation where it works? (Do not misread this as an objection, I'm just curious to know where it can work.) gd The '\ 's are not seen by make, they are interpreted by the shell gd that is invoked in the make rule executions, right? And for data, gd there is rarely the occasion it occurs in a make rule header... $(data_DATA) is a dependency of all, check, install, and distdir, in case data file need to be built. So it matters. Try FOO = f\ 1 all: $(FOO) and compare % make # GNU make make: *** No rule to make target `f 1', needed by `all'. Stop. % pmake # NetBSD make make: don't know how to make f\. Stop % fmake # FreeBSD make make: don't know how to make f\. Stop I think it'd be OK to have filenames with spaces in GNUmakefile.am. In that case, the generated rules have to be space-clean. I think it's worthwhile to consider Ralf's patch after he addresses some of my comments. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: 2 questions about libraries
Hi, Santosh [EMAIL PROTECTED] writes: For the second question, you can use the $(top_srcdir) variable and give the complete path of your library. example: 2Dinterpolation_LDADD = $(GLIB_CFLAGS) \ $(top_srcdir)/src/errors/libErrors.a \ $(top_srcdir)/src/lib/libLib.a I think you mean $(top_builddir). $(top_srcdir) is used to refers to source files. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: Problems getting dependencies compiled before executable....
Hi, [EMAIL PROTECTED] writes: By the way, if you don't mind me asking, what is the point of _DEPENDENCIES when you can just add library to _LDADD and Autotools will update dependency list automatically from that??? Usually, there's no point. However, there can be cases where automake cannot figure out that a library is part of link line, for example when the list of libraries is AC_SUBSTed in. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: How hardcode different default prefix? Hack Makefile.in bestway? use autoconf macro?
Hi, [EMAIL PROTECTED] writes: Is hacking definition of $(prefix) in Makefile.in the best way to change default prefix from something other than /usr/local??? Is there some macro to add to configure.in that would do the same? That seems like the ideal. Try searching for 'default prefix' in the autoconf documentation. The answer's in there. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: Removing dependencies
Bill Moseley [EMAIL PROTECTED] writes: I generate HTML docs from other source files. I have a single program build that knows how to generate the docs. So all I need to do is detect that any one HTML file is out of date and run build This is suppose to build the HTML docs when out of date, and install the HTML docs. Here's the Makefile.am: html_DATA = \ CHANGES.html \ INSTALL.html \ README.html \ [...] image_DATA = \ images/dotrule1.png \ images/logo.png depends = \ $(pod_dir)/CHANGES.pod \ $(pod_dir)/INSTALL.pod \ $(pod_dir)/README.pod \ [...] all: .html-stamp Remove this. You may need: all-local: $(html_DATA) to get these built during 'make all' rather than during 'make install'. .html-stamp: $(version_file) $(depends) cd $(srcdir)/../doc bin/build @touch $(srcdir)/.html-stamp EXTRA_DIST = $(html_DATA) $(image_DATA) .html-stamp This works fine, but if the HTML docs do not exist (such as from a CVS checkout) then Make dies because there's no target for .html. make: Fatal error: Don't know how to make target `CHANGES.html' I tried something like: $(html_DATA): .html-stamp Keep this. Also, if you only support using GNU make when developing this package, you may want to use the following more useful (but untested) rule: $(html_DATA): .html-stamp if test -f $@; then :; else rm -f $; done This'll allow you to rm CHANGES.html make and have CHANGES.html recreated. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: Removing dependencies
Hi, Raja R Harinath [EMAIL PROTECTED] writes: [snip] $(html_DATA): .html-stamp if test -f $@; then :; else rm -f $; done That should read: if test -f $@; then :; else rm -f $; $(MAKE) .html-stamp; done - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: Removing dependencies
Hi, Bill Moseley [EMAIL PROTECTED] writes: On Fri, 4 Apr 2003, Raja R Harinath wrote: Hi, Raja R Harinath [EMAIL PROTECTED] writes: [snip] $(html_DATA): .html-stamp if test -f $@; then :; else rm -f $; done That should read: if test -f $@; then :; else rm -f $; $(MAKE) .html-stamp; done Yes, that would be perfect, but I don't think I can require GNU make. How non-portable is that? Notice that this rule will be executed by only those people who edit one of the *.pod files, or who want to explicitly regenerate the HTML files rather than use the ones that were distributed by you. Ordinary users, who build from your distributed tarball will _not_ execute this rule, and shouldn't be affected. So, I don't think it's a major imposition to as for GNU make of those people who actually change the code or documentation. BTW -- something's not quite right in the syntax, it seems. if test -f CHANGES.html; then :; else rm -f .html-stamp; make .html-stamp; done /bin/sh: -c: line 1: syntax error near unexpected token `done' /bin/sh: -c: line 1: `if test -f CHANGES.html; then :; else rm -f .html-stamp; make .html-stamp; done' Yikes. I need coffee :-) Replace 'done' with 'fi'. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: $srcdir
Hi, Harlan Stenn [EMAIL PROTECTED] writes: But if I echo either $top_srcdir or $top_builddir, in the file tests/foo.test, they are both null, so I can't seem to find a way of referring to any files. AC_OUTPUT your test scripts using foo.in - foo rules, and include lines like: [EMAIL PROTECTED]@ in them. Either that, or AC_OUTPUT a vbls.conf.in - vbls.conf file which does this and source this file in from your scripts. That's too heavy-handed for tests. The idiom for tests is to use TESTS_ENVIRONMENT = srcdir=$(srcdir) top_srcdir=$(top_srcdir) This is assuming the test scripts are listed in check_TESTS. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: Quick question on optional builds with automake
Hi Kent, Kent Mein [EMAIL PROTECTED] writes: Hi I'm working on converting blender (www.blender.org) To automake/autoconf etc... I have the first part mostly working (producing 1 binary) The next stage I'd like to do is get it to build a second binary only when I type make blenderplayer I'd also like to do a make webplugin (which will create a shared library) Any pointers on how to do this? From reading the docs I was guessing bin_PROGRAMS = blender extra_PROGRAMS = blenderplayer extra_LTLIBRARIES = blenderplugin.la That is one way to go about it. However, you'll not be able to install these programs/plugins using the normal 'make install'. So, depending on what you want to do, it may make more sense to change your 'configure.in' and 'Makefile.am' to support --enable-blenderplayer --enable-webplugin Then, the standard 'make make check make install' will do the right thing. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: depcomp for texinfo + automake in guile
Hi, Tom Tromey [EMAIL PROTECTED] writes: Thi == Thien-Thi Nguyen [EMAIL PROTECTED] writes: Thi i could not find ready documentation (automake 1.6.1) on how to Thi emulate the include .deps/foo.Ptexi since, if i add that to Thi Makefile.am, it seems automake interprets that for itself instead Thi of passing it through to the end Makefile. Yes, that's right. Thi the workaround is to have configure run a program after invoking Thi config.status to do the job. is there a better way? Perhaps not :-(. This really isn't too different from what automake itself actually does. Thi my question is: is there a canonical way to do this w/in the Thi automake worldview that i've not yet discovered? if not, what Thi would be the best way to contribute general handling of .texi Thi generation to automake? It would be nice to let other tools that generate dependencies well integrate into automake seamlessly. As far as I know nobody has really thought about the problem though (you seem to be the first person to be interested). Perhaps automake should recognize the following idiom for adding new 'include .dep/*' lines: AM_DEP_FILES = $(DEPDIR)/foo.Ptexi $(DEPDIR)/bar.idl.Pcc It can just add these files to the DEP_FILES variable, and have the 'include' lines automatically added. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: perl path patch
Michael Pruett [EMAIL PROTECTED] writes: Here's a small patch against automake 1.6.2 which allows automake to use the copy of Perl in the user's path (which may differ from the path with which automake was built) as long as that version is sufficiently recent (where sufficiently recent here means Perl 5.6 or newer). Michael --- ./aclocal.in Mon Apr 22 00:35:15 2002 +++ ../automake-1.6.2/./aclocal.inWed Jun 26 12:41:42 2002 @@ -1,10 +1,7 @@ -#!@PERL@ +#!/bin/env perl It's /usr/bin/env on my GNU/Linux machine. # -*- perl -*- # @configure_input@ -eval 'case $# in 0) exec @PERL@ -S $0;; *) exec @PERL@ -S $0 $@;; esac' -if 0; - This is to re-execute the script with Perl in case somehow a Bourne shell started executing this script. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: automake warning using lib_LTLIBRARIES
Roger Leigh [EMAIL PROTECTED] writes: I'm getting this warning from automake: roger@whinlatter:~/gimp-print/newbuild$ automake automake: both `configure.ac' and `configure.in' present: ignoring `configure.in' automake: src/main/Makefile.am: `libgimpprint.la' is already going to be installed in `lib' [snip] ## Programs if BUILD_LIBGIMPPRINT lib_LTLIBRARIES = libgimpprint.la endif if BUILD_LIBGIMPPRINT bin_SCRIPTS = gimpprint-config endif EXTRA_SCRIPTS = gimpprint-config EXTRA_LTLIBRARIES = libgimpprint.la ^^^ My guess is that it complains about the EXTRA_LTLIBRARIES line. You don't need that line, since automake is supposed to figure it out itself. I'm not sure whether it's a bug or not. - 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: automake warning using lib_LTLIBRARIES
Raja R Harinath [EMAIL PROTECTED] writes: Roger Leigh [EMAIL PROTECTED] writes: I'm getting this warning from automake: roger@whinlatter:~/gimp-print/newbuild$ automake automake: both `configure.ac' and `configure.in' present: ignoring `configure.in' automake: src/main/Makefile.am: `libgimpprint.la' is already going to be installed in `lib' [snip] ## Programs if BUILD_LIBGIMPPRINT lib_LTLIBRARIES = libgimpprint.la endif if BUILD_LIBGIMPPRINT bin_SCRIPTS = gimpprint-config endif EXTRA_SCRIPTS = gimpprint-config EXTRA_LTLIBRARIES = libgimpprint.la ^^^ My guess is that it complains about the EXTRA_LTLIBRARIES line. You don't need that line, since automake is supposed to figure it out itself. I'm not sure whether it's a bug or not. ^^ I meant, I'm not sure whether the warning above is a bug or not. - 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: what is this shell call trying to solve?
Phil Edwards [EMAIL PROTECTED] writes: Been playing with 1.5 and have been pretty pleased with the support for source files in subdirectories. I have noticed however something which strikes me as odd: % make make all-am make[1]: Entering directory `/tmp/pme/foo' source='/home/pme/easysems/main.cc' object='main.o' libtool=no \ depfile='.deps/main.Po' tmpdepfile='.deps/main.TPo' \ depmode=gcc3 /bin/sh /home/pme/easysems/depcomp \ * g++ -DHAVE_CONFIG_H -I. -I/home/pme/easysems -I. -g -O2 -c -o *main.o `test -f /home/pme/easysems/main.cc || *echo '/home/pme/easysems/'`/home/pme/easysems/main.cc g++ -g -O2 -o semmanip getopt.o getopt1.o semmanip_opts.o main.o make[1]: Leaving directory `/tmp/pme/foo' % The call to the compiler, broken across three lines here and marked with '*', uses a shell expansion which doesn't make any sense. Something is visibly wrong here, but I don't know what. Everything works, but it looks like it's trying to test for a failure condition and... I dunno, do something strang in that condition. That code is there support non-srcdir builds in the face of 'make's with broken VPATH implementations. If you look at the Makefile, you'll see that it is checking to see whether 'make' said that the source file was in $(srcdir), and if not, the 'echo' supplies the $(srcdir). - 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: what is this shell call trying to solve?
Hi, Tom Tromey [EMAIL PROTECTED] writes: Hari == Raja R Harinath [EMAIL PROTECTED] writes: Hari That code is there support non-srcdir builds in the face of Hari 'make's with broken VPATH implementations. If you look at the Hari Makefile, you'll see that it is checking to see whether 'make' Hari said that the source file was in $(srcdir), and if not, the Hari 'echo' supplies the $(srcdir). Actually it is even more subtle than that, I think. For explicit rules (not suffix rules), there are some macros like $ that we can't use. But, we're talking about suffix rules like .c.lo: @AMDEP_TRUE@source='$' object='$@' libtool=yes @AMDEPBACKSLASH@ @AMDEP_TRUE@depfile='$(DEPDIR)/$*.Plo' tmpdepfile='$(DEPDIR)/$*.TPlo' @AMDEP BACKSLASH@ @AMDEP_TRUE@$(CCDEPMODE) $(depcomp) @AMDEPBACKSLASH@ $(LTCOMPILE) -c -o $@ `test -f $ || echo '$(srcdir)/'`$ We're fixing up what 'make' told us the source file was, and we ask 'make' about the source file name only in a suffix rule. For some versions of make, these macros only have values in suffix rules. So we have to do srcdir-searching by hand in explicit rules for GNU make, so that the code will continue to work in a srcdir-build context for vendor makes. Why would one do this the complicated way? You already know explicitly where source file is, so why would you fix it up with the shell fragment above? foo.lo: foo.c $(LTCOMPILE) -fsomething-special -c -o foo.lo $(srcdir)/foo.c I don't like this, but I don't see what we can do about it. Even finding a way to reject non-srcdir builds for non-GNU make won't help here. I agree. - 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: Recreate depfiles when regenerating Makefiles
Hi, Tom Tromey [EMAIL PROTECTED] writes: Hari == Raja R Harinath [EMAIL PROTECTED] writes: Hari Akim once suggested adding a facility to hook commands to files Hari listed in AC_CONFIG_FILES. The problem with this idea is that the information about which files is known when automake is run, not when autoconf is run. I meant it this way: AC_CONFIG_FILES([foo/Makefile]) and elsewhere, some _AM_* macro generates AC_CONFIG_FILE_HOOK([foo/Makefile], [# same commands as run for 'depfiles' AC_CONFIG_COMMAND ]) (Though, IIRC, Akim wanted this functionality as part of AC_CONFIG_COMMAND). Hari Anyway, till that date, it may make sense to handle this somewhat Hari hackily. One issue with generating the above command is that it is Hari safe to invoke the 'depfiles' CONFIG_COMMAND only in some cases, and Hari at the time 'automake' emits the Makefile regeneration code, it Hari doesn't know if it's safe yet. So, here goes: I think it is always safe to run the depfiles command. The command itself looks to see if the file it is modifying is an automake output. So I think it is ok to simply always run the `depfiles' rule. No. It is currently safe only if one of the AC_PROG_CC or AC_PROG_CXX commands is present in configure.in, thanks to the shenanigans in init.m4. That's why I went through the extra step. Thanks. - 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
Recreate depfiles when regenerating Makefiles
Hi,
One of the changes recently was to use the
./config.status foo/Makefile
syntax for regenerating makefiles, instead of
CONFIG_FILES=foo/Makefile CONFIG_HEADERS= ./config.status
However, implicit in the old command was the execution of the various
default CONFIG_COMMANDS, one of them being the 'depfiles' command
to recreate .dep/*.P files. This is necessary to handle addition of
files to *_SOURCES without manual intervention.
The closest new invocation is
./config.status foo/Makefile depfiles
This is of course a hack. This will change in the future once the
'depfiles' CONFIG_COMMAND no longer depends on $CONFIG_FILES to pick
out the Makefile it's supposed to look into. Akim once suggested
adding a facility to hook commands to files listed in AC_CONFIG_FILES.
Anyway, till that date, it may make sense to handle this somewhat
hackily. One issue with generating the above command is that it is
safe to invoke the 'depfiles' CONFIG_COMMAND only in some cases, and
at the time 'automake' emits the Makefile regeneration code, it
doesn't know if it's safe yet. So, here goes:
From Raja R Harinath [EMAIL PROTECTED]
* automake.in (handle_languages): Emit an automake
internal variable 'am__depfiles_maybe'.
* lib/am/configure.am (%MAKEFILE%): Use $(am__depfiles_maybe).
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1254
diff -u -p -u -r1.1254 automake.in
--- automake.in 2002/01/01 22:01:07 1.1254
+++ automake.in 2002/01/01 23:07:54
@@ -1535,6 +1535,7 @@ sub handle_languages
{
# Set location of depcomp.
define_variable ('depcomp', \$(SHELL) $config_aux_dir/depcomp);
+ define_variable ('am__depfiles_maybe', 'depfiles');
require_conf_file ($am_file.am, FOREIGN, 'depcomp');
@@ -1567,6 +1568,7 @@ sub handle_languages
else
{
define_variable ('depcomp', '');
+ define_variable ('am__depfiles_maybe', '');
}
my %done;
Index: lib/am/configure.am
===
RCS file: /cvs/automake/automake/lib/am/configure.am,v
retrieving revision 1.10
diff -u -p -u -r1.10 configure.am
--- configure.am 2001/10/26 09:56:42 1.10
+++ configure.am 2002/01/01 23:07:54
@@ -28,7 +28,7 @@
## This rule remakes the Makefile.
%MAKEFILE%: %MAINTAINER-MODE% %MAKEFILE-IN% %MAKEFILE-DEPS% $(top_builddir)/config.status
- cd $(top_builddir) $(SHELL) ./config.status %CONFIG-MAKEFILE%
+ cd $(top_builddir) $(SHELL) ./config.status %CONFIG-MAKEFILE% $(am__depfiles_maybe)
- 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: setting additional libtool runtime variables
[EMAIL PROTECTED] writes: On Mon, 15 Oct 2001, Gary V. Vaughan wrote: On Sun, Oct 14, 2001 at 10:03:38PM -0400, [EMAIL PROTECTED] wrote: Is there a way to tell libtool that it needs to set some additional runtime variables in addition to LD_LIBRARY_PATH when trying to test run an executible before its installed? I have some data files and the path gets built into the binary, but can be overridden with an environment variable. You could use a wrapper script that sets the environment up and then execs the real binary... CVS autoconf does this in the tests dir. Or you could set Automake's TESTS_ENVIRONMENT (sp?) variable in your Makefile.am. This isn't part of the tests target, its more of a `let the user try it before they install it'. Basically, I want the wrapper script setup by libtool to contain an additional variable. It just happens that the 'autoconf' wrapper scripts are in the 'tests' directory. You can use that approach in other places too. - 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: several automake questions
Hi, Alexandre Duret-Lutz [EMAIL PROTECTED] writes: mcmahill == mcmahill [EMAIL PROTECTED] writes: mcmahill 1) How can I specify a different directory or mcmahill subdirectory for a program? The application is a cgi mcmahill program which might, for example, end up in mcmahill /usr/local/libexec/cgi-bin. The standard things like mcmahill bin_PROGRAMS or libexec_PROGRAMS just don't get me to mcmahill the right place. I somehow need a cgibin_PROGRAMS... cgibindir = $(libexecdir)/cgi-bin cgibin_PROGRAMS = mumble mumble_SOURCES = ... That should be cgibinexecdir = $(libexecdir)/cgi-bin cgibinexec_PROGRAMS = mumble so that things work as expected with 'make install-exec'. - 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: AM_CONDITIONAL
Hi, Jens Krüger [EMAIL PROTECTED] writes: Am Montag, 24. September 2001 17:08 schrieben Sie: [snip] You'll have to rewrite your configure script to generate all directories _even_ if not all the features are used. Automake tries to ensure that 'make dist' enters all directories and copies all the files. The generated package can later be configured with different settings, after all. So, all the directories and Makefiles should exist, even if they're never invoked during some builds. I had a look at the tar.gz file and I found all files needed for the distribution. I took this tarball, untar it, run configure with all possible options and packages and it works fine. That tarball is the result of the first (outer) 'make dist', which likely was run in your development tree. It was likely generated from a tree which had many/most/all of the options selected, so that all directories existed in the build tree. No wonder it has everything needed. (Even if the latest configure didn't have some options selected, your tree may have had slightly stale makefiles left over from earlier 'configure's with different options, essentially leaving you with a complete tree nonetheless.) My problem was and is that the make distcheck doesn't work. I have no possibility to run the configure script during make distcheck with any option. In my opinion the reason is based on the 'make dist' call during make distcheck. Obviously. We know one 'make dist' succeeded, since it wouldn't have created the '=build' directory otherwise. It is the inner 'make dist', the one inside the '=build' directory, that is failing. For me is there no reason to 'make dist' during 'make distcheck' or may you give me one? Well, one reason is it's automake philosophy (or cussedness, if you want it that way ;-). Basically, you want the user of the generated tarball to have all the privileges of a developer -- including the expectation that a 'make dist' in a default configured build directory will generate a complete tarball with all features. Another reason is that it is a great debugging feature. It helps you root out mistakes that you may have made w.r.t builddir, srcdir, dist, nodist, BUILT_SOURCES and other issues. It all boils down to this: the tarball generated by 'make dist' should NOT depend on what flags you passed to 'configure' in the build tree where you ran 'make dist' or 'make distcheck'. - 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: 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: AM_CONDITIONAL
Jens Krüger [EMAIL PROTECTED] writes: [snip] AM_CONDITIONAL(BUILD_LAKESHORE_MODULE, test $my_build_lakeshore = yes) the contents of the corresponding Makefile looks like: if BUILD_LAKESHORE_MODULE SUBDIRS= . MySource MySink MyFilter SoNXFileReader SoNXLakeShore SoNXDataGenerator \ FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot else SUBDIRS= . MySource MySink MyFilter SoNXFileReader SoNXDataGenerator \ FiNXDataSelector FiNXDimensionCutter \ SiNXTableBrowser SiNXFileWriter GL3DPlot SiNX2DPlot endif This code works fine if I make a normal build. Also the 'make dist' works, but the 'make distcheck' doesn't work. It breaks with these messages: /bin/sh: cd: SoNXLakeShore: Datei oder Verzeichnis nicht gefunden Can you translate the message to English? I'm guessing that the directory doesn't exist (since that's pretty much the main reason 'cd' would complain in a build tree). [snip] The next step I've done was to call make manually in the =build dir and it works. I think the reason for the break of distcheck is based on the DIST_SUBDIRS macro. My question is: Is this behaviour a bug or a feature. 'make distcheck' is based on DIST_SUBDIRS since you want to test as much of your package as possible. It is a feature. The next question, is there a workaround to solve my problem? Given my guess, you should ensure that all directories and all Makefiles are created by the 'configure' scripts, even if the build will not enter those directories. - 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: System configuration during install
Hi, Lawrence, David (STEI) [EMAIL PROTECTED] writes: I am confiscating a large project to autotools. I would like to know if there is a recommended means of adding a daemon to the etc/rc.d/init.d directory and then running chkconfig to add the daemon to run during init. I think thats a lot beyond the scope of Automake. Anyway 'chkconfig' appears to be a Redhat-only tool, and /etc/rc.d/init.d is almost definitely a Redhat peculiarity -- so it isn't the right abstraction if you want your package to be portable, even to other Linux distributions. I know how to do it in a script, do the autotools have a specific way it is recommended to add it to make install? AFAI know, the only system integration that happens on a standard 'make install' is the invocation of 'install-info' to regenerate the 'dir' file in $infodir. You can always put in an 'install-exec-hook' to do the postprocessing. However, I don't think you'll be doing any favours to packagers (like maintainers of RPM or DEB packages). Also, people may not like 'make install' changing the boot-time behaviour of a machine, and/or may not have permissions to modify the boot-time settings. I would suggest putting in a 'setup-boot' target to do this, and ask people to explicitly invoke that rule to integrate your program into the boot setup. - 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: DEPDIR not set by current CVS Automake
Hi, Robert Boehne [EMAIL PROTECTED] writes: I'm having problems with my Libtool/Automake project when using dependency tracking. It seem that the variable DEPDIR isn't set anywhere in any of the Makefiles. DEPDIR is AC_SUBSTed in by depend.m4. Do you have the right version? Is AM_SET_DEPDIR properly invoked in init.m4? - 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: Supporting include in Makefiles
Hi, Akim Demaille [EMAIL PROTECTED] writes: BTW, does Automake *use* that feature? If not, then it should not provide this macro IMHO. It should stop distributing macros, that's Autoconf job, not Automake's. It is used internally to support the dependency tracking mechanism. It is almost definitely not intended as a generic mechanism to support Makefile includes. After all, automake already has it's own support for including makefile fragments -- and that mechanism is already portable to 'make's that don't support any form of 'include's. - 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: sub conditionals_true_when (@@) [PATCH]
Richard Boulton [EMAIL PROTECTED] writes:
On Wed, Jun 13, 2001 at 11:44:52AM +0300, Kalle Olavi Niemitalo wrote:
This bug is also causing the @TRUE@ conditions reported by
Richard Boulton in Bug with conditionals. [PATCH].
You're right, this does seem to be the main cause of the problem I
reported.
I tried fixing the problem (by passing by reference instead).
[snip]
# $BOOLEAN
-# conditionals_true_when (@CONDS, @WHENS)
+# conditionals_true_when (\@CONDS, \@WHENS)
#
[snip]
+sub conditionals_true_when ($$)
{
-my (@conds, @whens) = @_;
+my ($condsref, $whensref) = @_;
Isn't it cleaner to use
sub conditions_true_when(\@@)
{
my ($condsref, @whens) = @_;
You also get the benefit of type-checking.
- if ! conditionals_true_when ((@parent_conds), ($vcond));
+if ! conditionals_true_when ([@parent_conds], [$vcond]);
This would then be,
if ! conditionals_true_when(@parent_conds, $vcond)
- 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: The %.o: %.cc rule
Tom Tromey [EMAIL PROTECTED] writes: Hair == Raja R Harinath [EMAIL PROTECTED] writes: Clark test_SOURCES = d1/s1.cc d2/s2.cc Hair Try using Hair AUTOMAKE_OPTIONS = subdir-objects subdir-objects will cause Makefile to build d1/s1.o and d2/s2.o. Without it, the above test_SOURCES will still work but the .o files will end up in `.'. Yep. I forgot to include the actual context of the original question. Clark I am attempting to modify automake to support paths and want Clark the output files to end up in the same directory structure as Clark the original files. That seems to suggest he wasn't aware of 'subdir-objects'. - 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
[PATCH] Make ASSIGNMENT_PATTERN less greedy
Hi, The recently added ASSIGNMENT_PATTERN is a little too greedy. Given FOO=-DBAR=baz it incorrectly matches the macro name to be 'FOO=-DBAR' rather than just 'FOO'. Here's an obvious fix, and a possible testcase. from Raja R Harinath [EMAIL PROTECTED] * automake.in (ASSIGNMENT_PATTERN): Make variable-name pattern stop at the first '='. Index: automake.in === RCS file: /cvs/automake/automake/automake.in,v retrieving revision 1. diff -u -p -u -r1. automake.in --- automake.in 2001/05/12 12:36:03 1. +++ automake.in 2001/05/12 23:31:43 @@ -125,7 +125,7 @@ my $SUFFIX_RULE_PATTERN = '^\.([a-zA-Z0- # leading tabs here then we need to make the reader smarter, because # otherwise it will think rules like `foo=bar; \' are errors. my $MACRO_PATTERN = '^[A-Za-z0-9_@]+$'; -my $ASSIGNMENT_PATTERN = '^ *([^ \t]*)\s*([:+]?)=\s*(.*)$'; +my $ASSIGNMENT_PATTERN = '^ *([^ \t=]*)\s*([:+]?)=\s*(.*)$'; # This pattern recognizes a Gnits version id and sets $1 if the # release is an alpha release. We also allow a suffix which can be # used to extend the version number with a fork identifier. #! /bin/sh # Test various variable definitions that include an '=' sign . $srcdir/defs || exit 1 cat Makefile.am 'END' MY_FLAGS_1=-DABC=345 MY_FLAGS_2= -DABC=345 MY_FLAGS_3 =-DABC=345 MY_FLAGS_4 = -DABC=345 END $AUTOMAKE || exit 1 exit 0 - 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: Dependency to update Makefile
Hi, Tom Tromey [EMAIL PROTECTED] writes: 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 before processing continues. We rely on this feature in the automatic rebuilding rules. That also means that BUILT_SOURCES will be built before Makefile (if any released automake is used). So, it matters if the target being built out-of-turn is mentioned in BUILT_SOURCES or not. - 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: SGI mode depcomp breaks when '.' appears in source filenames twice
Thomas Dickey [EMAIL PROTECTED] writes: On Thu, Apr 05, 2001 at 10:32:02PM -0500, Raja R Harinath wrote: Well -- the whole idea is to remove the rule targets. I know of only one use of multiple colons on a line -- in GNU make. Even there, everything before a ':' is a rule target. My comment "limited to the first ':'" may not be accurate, but I don't see any advantage to not always removing everything before a ':'. it sounds as if you're saying that rule :: action is GNU-make specific, which is not true, of course. Whoops. I forgot all about that. I was thinking of foo.o bar.o: %.o: %.h; ... Anyway, we are getting off-topic :-) The 'sed' rule under question is applied to what's generated by an SGI compiler's dependency-generator. - 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: CVS autoconf + CVS automake = autoconf doesn't know its version
"Lars J. Aas" [EMAIL PROTECTED] writes: On Thu, Apr 05, 2001 at 05:36:48PM -0500, Raja R Harinath wrote: : The following patch fixes a problem with CVS autoconf, if a recent : enough CVS snapshot of automake was used on it. This is my proposal. @PACKAGE doesn't seem to be needed. @PACKAGE@ is needed. It is used by Makefile.in for 'make dist'. Index: Makefile.am === RCS file: /cvs/autoconf/Makefile.am,v retrieving revision 1.42 diff -u -r1.42 Makefile.am --- Makefile.am 2001/03/27 12:02:16 1.42 +++ Makefile.am 2001/04/06 11:05:17 @@ -33,6 +33,7 @@ # FIXME: Current Automakes are blind and cannot see inner AC_SUBST, # so help it. PACKAGE_NAME = @PACKAGE_NAME@ +VERSION = @VERSION@ # FIXME: # s/distpackageDATA/dist_pkgdata_DATA/ 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. - 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
CVS autoconf + CVS automake = autoconf doesn't know its version
Hi, The following patch fixes a problem with CVS autoconf, if a recent enough CVS snapshot of automake was used on it. The problem is that 'automake' now depends on the AC_SUBSTs in AM_INIT_AUTOMAKE to subst in VERSION and PACKAGE. Since the same 'automake' doesn't understand 'm4_include's, it does not see the actual definition of AM_INIT_AUTOMAKE (autoconf bypasses the 'aclocal' mechanism). Here's a patch to autoconf to fix this. Index: aclocal.m4 === RCS file: /cvs/autoconf/aclocal.m4,v retrieving revision 1.9 diff -u -p -u -r1.9 aclocal.m4 --- aclocal.m4 2000/05/24 13:00:34 1.9 +++ aclocal.m4 2001/04/05 22:35:48 @@ -3,3 +3,11 @@ m4_include([m4/missing.m4]) m4_include([m4/sanity.m4]) m4_include([m4/atconfig.m4]) m4_include([m4/m4.m4]) + +# Most versions of 'automake' subst these in when 'AM_INIT_AUTOMAKE' +# is present in configure.in. However, some versions don't -- they +# depend on the fact that aclocal.m4 will have lines that subst them in. +# Some of those versions also don't understand 'm4_include'. +# Help them along. +AC_SUBST(PACKAGE) +AC_SUBST(VERSION) - 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: AM_MAKE_INCLUDE
Hi, Ralf Corsepius [EMAIL PROTECTED] writes: An observation with cvs-autoconf and automake-1.4d: Given this configure.in: AC_INIT(Makefile.am) AM_INIT_AUTOMAKE(foo,0,no) AM_MAKE_INCLUDE AC_OUTPUT(Makefile) # ./configure [snip] Note: style of include "include" Now touching/editing configure.in and rerunning make: # touch configure.in # make [..] /bin/sh ./config.status --recheck running /bin/sh ./configure --no-create --no-recursion [snip] Note: style of include "#" I've seen something similar. Running './config.status --recheck' again seems to fix it. Unfortunately, the output of make is redirected to /dev/null. My suspicion is that this could do with the timestamp warning sometimes emitted by GNU make. Is the directory NFS mounted from a Solaris m/c? - 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: AM_MAKE_INCLUDE
Ralf Corsepius [EMAIL PROTECTED] writes: [snip] Meanwhile, I think to have found the cause. Somehow, after having touched configure or configure.in, "make" runs the "include check" by recursively running make. Due to recursively running make, __gmake__ emits a "Entering directory ..." message to __stdout__, which interferes with autoconf's AM_MAKE_INCLUDE check, which expects a string containing plain "done" instead of "make[1]:Entering directory ..done", which it actually seems to receive. That makes sense. I think those are supressed when you run GNU make with the '-s' option. (The -s option was present in Unix 7th Edition too, so it can pretty much be used with impunity.) - 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: 81-lang-extensions.patch
Hi,
Akim Demaille [EMAIL PROTECTED] writes:
+while (my ($attr, $value) = each %option)
{
[snip]
+ if ($attr eq 'ansi')
{
+ $lang_obj-ansi ($value);
}
+ elsif ($attr eq 'autodep')
{
+ $lang_obj-autodep ($value);
}
+ elsif ($attr eq 'compile')
+ {
+ $lang_obj-compile ($value);
+ }
[snip]
Wouldn't this be more compact and readable without the loop?
$lang_obj-ansi($options{'ansi'})if exists $options{'ansi'};
$lang_obj-autodep ($options{'autodep'}) if exists $options{'autodep'};
$lang_obj-compile ($options{'compile'}) if exists $options{'compile'};
# ...
delete $options{$_} for (('ansi', 'autodep', 'compile', ...));
complain(...) if (keys %options);
- 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: 81-lang-extensions.patch
Hi,
Akim Demaille [EMAIL PROTECTED] writes:
Raja R Harinath [EMAIL PROTECTED] writes:
[snip]
| Wouldn't this be more compact and readable without the loop?
|
| $lang_obj-ansi($options{'ansi'})if exists $options{'ansi'};
| $lang_obj-autodep ($options{'autodep'}) if exists $options{'autodep'};
| $lang_obj-compile ($options{'compile'}) if exists $options{'compile'};
| # ...
|
| delete $options{$_} for (('ansi', 'autodep', 'compile', ...));
| complain(...) if (keys %options);
Oh yes, definitely! Thanks!
But in fact, this code is made to be killed soon: recent versions of
Class::Struct finally (aah!) provide a `new' which accepts a hash to
initialize the object. We won't need this code, and probably we would
need register_language either, just calls to `new'.
But, I thought the decision was to support Perl 5.005_03. The version
of Class::Struct with that doesn't seem to support initialization by
passing a hash to 'new'.
- 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: depcomp changes for IRIX
Hi, David Kaelbling [EMAIL PROTECTED] writes: I recently built libglade/0.16 for IRIX 6.2, and noticed a small flaw in depcomp. To use the native MipsPRO compilers I made the changes below. The first one is important -- passing the flag to the proper compiler phase. [...] sgi) if test "$libtool" = yes; then -"$@" "-Wc,-MDupdate,$tmpdepfile" +"$@" "-Wp,-MDupdate,$tmpdepfile" This already appears to have been fixed in the CVS version of 'depcomp'. The second is optional; to shorten some very long dependency lines I pruned out all the system headers (all headers with absolute paths). [...] echo "$object : \\" "$depfile" - sed 's/^[^:]*: / /' "$tmpdepfile" "$depfile" + sed -e 's/^[^:]*: / /' -e 's# /[^ ]*##g' "$tmpdepfile" "$depfile" This may not be a good idea. This heuristic would work only if the Makefile.am used relative paths for same tree include directories, and either * you're building in the source tree * you're building in a separate tree, but provided a relative path to the source tree Also, in general, you also need to trust the compiler not to convert relative include paths to absolute while generating dependencies. Since, in this case, the compiler is "known", this isn't an issue. - 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: automake asks for a depcomp file
Hi, Stephen Torri [EMAIL PROTECTED] writes: Running automake (CVS compiled) against my configure.in causes the message "automake: configure.in: required file `master/depcomp' not found. There is no mention to a file called "depcomp" in configure.in or master/Makefile.am. In the master/Makefile.in there is mention to it: depcomp = $(SHELL) $(top_srcdir)/depcomp. What is the purpose of this file? Copy the file from the automake distribution or from $prefix/share/automake into the top directory of your source tree (the message is buggy). The 'depcomp' program is used for automatic dependency generation support. Previous versions of automake supported dependency generation with GNU make, GCC, and only by the "maintainer". With 'depcomp', automake now supports dependency generation with more 'make's, more compilers, and at the "user" site. - 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
[PATCH] depcomp and gcc3 still not safe enough
Hi, GCC 3.0 doesn't still exactly implement exactly what 'depcomp' wants. The problem is that if the compile fails, the file specified to -MF is deleted too. With 'gcc -MF $depfile', $depfile is deleted. But, $depfile is eventually included by the Makefile -- so subsequent 'make' invocations will fail, since an included file doesn't exist. I don't know if this a GCC bug. I'm assuming it's not -- it makes sense to clean up if the compile fails; the compiler doesn't provide rollback for -o, why should it provide rollback for -MF. Here's a patch to fix this problem. (The 'if' statement looks slightly peculiar, but it matches similar 'if's used in the rest of the file.) from Raja R Harinath [EMAIL PROTECTED] * depcomp (gcc3): Protect against the compiler deleting the dependency output file. Index: depcomp === RCS file: /cvs/automake/automake/depcomp,v retrieving revision 1.17 diff -u -p -u -r1.17 depcomp --- depcomp 2001/02/10 01:26:54 1.17 +++ depcomp 2001/02/18 00:52:27 @@ -51,8 +51,14 @@ case "$depmode" in gcc3) ## gcc 3 implements dependency tracking that does exactly what ## we want. Yay! - exec "$@" -MT "$object" -MF "$depfile" -MD -MP - ;; + if "$@" -MT "$object" -MF "$tmpdepfile" -MD -MP; then : + else +stat=$? +rm -f "$tmpdepfile" +exit $stat + fi + mv "$tmpdepfile" "$depfile" + ;; gcc) ## There are various ways to get dependency output from gcc. Here's - 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: [PATCH] depcomp and gcc3 still not safe enough
Hi, Raja R Harinath [EMAIL PROTECTED] writes: GCC 3.0 doesn't still exactly implement exactly what 'depcomp' wants. The problem is that if the compile fails, the file specified to -MF is deleted too. With 'gcc -MF $depfile', $depfile is deleted. But, $depfile is eventually included by the Makefile -- so subsequent 'make' invocations will fail, since an included file doesn't exist. [snip] * depcomp (gcc3): Protect against the compiler deleting the dependency output file. [snip] (Sorry to followup to myself). A more elaborate solution (assuming the GCC behaviour is not a bug), is to 1. copy the old 'gcc3' code to a 'gcc3-unsafe' mode 2. apply the above patch to the 'gcc3' part 3. extend the 'make' include/.include detection to also search for 'sinclude/-include' keywords 4. If 'gcc3' and 'sinclude/-include' are supported, change $depmode to 'gcc3-unsafe', and don't bother creating the dummy .Plo files in config.status I'm not sure it's worth the bother :-) - 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
Revert setting of CONFIG_COMMANDS when running config.status
Hi,
Please revert the CONFIG_COMMANDS part of
2001-02-04 Kevin Ryde [EMAIL PROTECTED]
* automake.in (handle_configure): Call config.status with empty
CONFIG_LINKS and CONFIG_COMMANDS when regenerating a file.
This doesn't work with beta autoconf 2.49d and
AC_OUTPUT(outputs, commands)
syntax. For example, 'automake's configure.in uses
AC_OUTPUT([Makefile automake aclocal m4/Makefile tests/Makefile],
[chmod +x automake aclocal])
However,
automake: $(top_builddir)/config.status automake.in
cd $(top_builddir) \
CONFIG_FILES=$@ CONFIG_HEADERS= CONFIG_LINKS= CONFIG_COMMANDS= \
$(SHELL) ./config.status
doesn't run the 'chmod +x automake'. This is because the old
AC_OUTPUT syntax appears to be internally implemented via
CONFIG_COMMANDS, and the explicit setting interferes with that.
This only affects beta autoconf, and CONFIG_COMMANDS was introduced
only with beta autoconf. So, it is safe to revert this part.
I don't think similar changes should be incorporated in the future.
It would be better to migrate to the new config.status command line
interface if AC_PREREQ(2.50) is seen,
./config.status --files=$@
rather than depend on specific details of the implementation of
config.status.
I've attached a patch only to revert the CONFIG_COMMANDS case. I
think the CONFIG_LINKS= part in the above is harmless.
- Hari
from Raja R Harinath [EMAIL PROTECTED]
* automake.in (handle_configure): Revert part of
'2001-02-04 Kevin Ryde [EMAIL PROTECTED]'. Don't
set CONFIG_COMMANDS explicitly.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.871
diff -u -p -u -r1.871 automake.in
--- automake.in 2001/02/09 03:39:18 1.871
+++ automake.in 2001/02/09 18:52:50
@@ -3185,7 +3185,7 @@ sub handle_configure
. "\t CONFIG_FILES="
. (($relative_dir eq '.') ? '$@' : '$(subdir)/$@')
. $colon_infile
- . ' CONFIG_HEADERS= CONFIG_LINKS= CONFIG_COMMANDS= $(SHELL) ./config.status'
+ . ' CONFIG_HEADERS= CONFIG_LINKS= $(SHELL) ./config.status'
. "\n\n");
if ($relative_dir ne '.')
@@ -3437,7 +3437,7 @@ sub handle_configure
. '$@' . ($need_rewritten
? (':' . join (':', @inputs))
: '')
- . ' CONFIG_HEADERS= CONFIG_LINKS= CONFIG_COMMANDS= $(SHELL) ./config.status'
+ . ' CONFIG_HEADERS= CONFIG_LINKS= $(SHELL) ./config.status'
. "\n");
push (@actual_other_files, $local);
--
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: 26-makesort.patch
Akim Demaille [EMAIL PROTECTED] writes: [snip] For instance, I find it quite annoying to have to know that Automake knows the -local targets: the code of 25 makes it possible for users to have just there own `clean:' target which will be appended to the existing code. That seems counter to current 'automake' behaviour. IIRC, if automake sees a "special" target in Makefile.am, it won't generate code for that target. E.g., if the Makefile.am has a 'check:' target, the builtin test harness will not be generated. - 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: More an autopackage
Hi, Pavel Roskin [EMAIL PROTECTED] writes: [snip] This module may be very valuable for you if you want to create packages not as root. GNU tar cannot be tricked into hardcoding the ownership different from the actual ones (as far as I know). You can use 'fakeroot' (now called 'libtricks' I think) from Debian. It is essentially an LD_PRELOAD that overrides getuid/open etc. and makes a process think that it's executing as root. - 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: Support for configure.ac
Lars Hecking [EMAIL PROTECTED] writes:
| At no time an old copy of automake is run.
You don't seem to understand. Make a
diff automake.in automake
and I think you'll see what I mean.
% grep @CONFIGURE_AC@ Makefile.in
$(srcdir)/stamp-vti: automake.texi $(top_srcdir)/@CONFIGURE_AC@
%
If autoconf, not automake is responsible for substituting @CONFIGURE_AC@
in the Makefile, then this simply doesn't work with autoconf-2.13, only
with autoconf-cvs.
I see this even with an installed automake. It appears that
'texi-vers.am' doesn't have the CONFIGURE_AC transform before being
inserted into Makefile.in. From automake.in, in handle_texinfo,
around line 2277
$output_rules .=
file_contents_with_transform
('s/\@TEXI\@/' . $info_cursor . '/g; '
. 's/\@VTI\@/' . $vti . '/g; '
. 's/\@VTEXI\@/' . $vtexi . '/g;'
. 's,\@MDDIR\@,' . $conf_pat . ',g;',
'texi-vers');
Note the lack of the @CONFIGURE_AC@ transform.
- 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: new depcomp causes trouble w/fileutils
Jim Meyering [EMAIL PROTECTED] writes:
I use the gcc snapshot of the day (checked out 2001-01-11.04h59 UTC)
and tried putting your latest depcomp into fileutils. It worked fine
for builds in a directory that was already configured (stale depmode?),
Either that or 'config.cache' -- the dependency mode is determined at
'configure' time and cached.
but when I ran `make distcheck', it ended up running in gcc3 mode and
failed because it put preprocessor output in the .o file.
The symptom was that linking failed because the .o file wasn't valid.
Here's s tiny test case that tries to demonstrate what happened:
$ cat k.c
int foo () {}
$ DEPENDENCIES_OUTPUT=1 gcc -c -o k.o k.c -M -MT k.o -MF k.Po
$ cat k.o
# 1 k.c
int foo () {}
I'm using automake-1.4b.
| 2001-01-10 Tom Tromey [EMAIL PROTECTED]
|
| * depcomp: Handle gcc 3.
I think this is a GCC bug, not a problem with 'automake'. For some
reason, it is treating the -c as a -E.
- 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: Automake Real Millenium Beta
Tom Tromey [EMAIL PROTECTED] writes: I think the real start of the new millenium deserves a new Automake as well. To that end, I've updated the automake version to 1.4b and put a release up. The cvs automake is now `1.4c'. There are plenty of bugs left, I'm sure. Some known issues: * The documentation is not nearly up to date * There are several bugs that haven't been fixed. For instance, the new dependency tracking code probably won't work with BSD make. I don't have a BSD box for testing :-( * There are some patches I haven't yet looked at. Please do consider the patch in http://sources.redhat.com/ml/automake/2000-12/msg3.html It cleans up 'depcomp' handling. (This may already be on your todo list, but I wanted to make sure you'll consider this -- the message didn't have a [PATCH] tag, and was at the end of a thread which you may have missed.) - 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
Handle Libtool from multi-language-branch
Hi,
The following patch adds minimal support for Libtool from the
multi-language-branch.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.810
diff -u -p -u -r1.810 automake.in
--- automake.in 2000/12/22 05:52:37 1.810
+++ automake.in 2000/12/22 20:45:26
@@ -194,6 +194,8 @@ $libtool_line = 0;
# Files installed by libtoolize.
@libtoolize_files = ('ltmain.sh', 'config.guess', 'config.sub');
+# ltconfig appears here for compatibility with old versions of libtool.
+@libtoolize_sometimes = ('ltconfig', 'ltcf-c.sh', 'ltcf-cxx.sh', 'ltcf-gcj.sh');
# TRUE if we've seen AM_MAINTAINER_MODE.
$seen_maint_mode = 0;
@@ -6657,9 +6659,7 @@ sub initialize_global_constants
"config.guess", "config.sub", "AUTHORS", "BACKLOG", "ABOUT-GNU",
"libversion.in", "mdate-sh", "mkinstalldirs", "install-sh",
'texinfo.tex', "ansi2knr.c", "ansi2knr.1", 'elisp-comp',
- # ltconfig appears here for compatibility with old versions
- # of libtool.
- 'ylwrap', 'acinclude.m4', @libtoolize_files, 'ltconfig',
+ 'ylwrap', 'acinclude.m4', @libtoolize_files, @libtoolize_sometimes,
'missing', 'depcomp', 'compile', 'py-compile'
);
- 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: distributing files generated by configure
Hi, Derek R. Price [EMAIL PROTECTED] writes: I have several files which are generated by configure that I want three things to happen to. 1) Created in $(srcdir) Then they shouldn't be created by 'configure' :-) rather than $(builddir) or, alternately and second best, targets added which make the $(srcdir) counterparts dependent on the $(builddir) versions. I don't like option 2 because a lot of diffing and touching will have to be going on to avoid updating unchanged files. 2) Removed from distclean 3) Added to dist The reason for this is to allow platforms which can't run configure (Win32) to checkout from our CVS repository and build as correctly as if they had grabbed a generated distribution. The premise is that any file checked into CVS should be in $(srcdir) and should not be removed from $(srcdir) by distclean. Our version.c file is an example of one of these files - it is now generated with configure based on the AM_INIT_AUTOMAKE version. Here's what's in Makefile.am of autoconf's latest CVS version. ## -- ## ## Maintainer rules. ## ## -- ## ## acversion.m4. ## # - acversion.m4 needs to be updated only once, since it depends on # configure.in, not on the results of a 'configure' run. # - It is guaranteed (with GNU Make) that when the version in configure.in # is changed, acversion.m4 is built only after the new version number is # propagated to the Makefile. (Libtool uses the same guarantee.) acversion.m4: $(srcdir)/acversion.m4.in $(srcdir)/configure.in sed 's,@VERSION\@,$(VERSION),g' $(srcdir)/acversion.m4.in acversion.tm4 mv acversion.tm4 $(srcdir)/acversion.m4 I think this exactly mirrors your requirements for version.c and CVSvn.texi. The idea is that only the maintainer needs to run these rules, since every 'configure' run with that package will generate the same file, anyway. That's why I said that these probably shouldn't be created by configure. The only downside being the necessity of an explicit rule with a 'sed' command, which I don't see as being too onerous. BTW, why do you need to 'configure' or 'sed' substitute a version number into a .c file -- you already have config.h which defines the symbol 'VERSION' to the version number string. - 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: AC_CONFIG_FILES problem
Harlan Stenn [EMAIL PROTECTED] writes: I'm generating a site-local file during configure that I use in AC_CONFIG_FILES. The filename is in the $GUTS variable, and I create the target via: GUTS=$build_cpu-localname echo stuff $GUTS AC_CONFIG_FILES([foo:foo-top.in:$GUTS:foo-bot.in]) Would AC_SUBST_FILE be more appropriate? Do you have any @...@ substitutions in $GUTS that can't be done otherwise. Also, automake detects: harlan@bali gmake cd . /bin/sh /home/harlan/src/foo/missing --run automake --foreign Makefile configure.in: 74: required file `./$GUTS' not found What's a good way to solve this problem? Well, the AC_CONFIG_FILES are the set of files that automake automatically generates config.status rules for. If you can stand writing Makefile.am rules instead, you can remove the $GUTS config file from AC_CONFIG_FILES and use: EXTRA_DIST += foo-top.in foo-bot.in foo: $(srcdir)/foo-top.in $(GUTS) $(srcdir)/foo-bot.in config.status CONFIG_HEADERS= CONFIG_FILES=foo:foo-top.in:$(GUTS):foo-bot.in \ $SHELL ./config.status or a more readable command with a beta autoconf (2.49a): $SHELL ./config.status --file=foo:foo-top.in:$(GUTS):foo-bot.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: How to install config.h
Ossama Othman [EMAIL PROTECTED] writes: On Fri, Oct 27, 2000 at 08:44:40PM +0100, Gary V. Vaughan wrote: Hmmm. I think that installing config.h is a bad idea under any circumstances. I talk about this in some detail in the ``Project'' chapters of the Goat Book (linked from my homepages), and offer an ugly but functional solution. Even if you don;'t go for that solution all out, there is no getting away from the fact that a certain amount of rewriting is an absolute must. I'm not sure that I agree with you, though I confess that I probably haven't thought about this issue as much as you. Please feel free to correct me. :-) But, you seem to agree ;-) If the macros placed in the package specific config.h are named so that they are specific to the given package then why is installing that header a problem. For example, if my config header has the following: /* I'm assuming that "FOO" is a fairly unique package name. */ #ifndef FOO_CONFIG_H #define FOO_CONFIG_H #define FOO_HAS_SOME_FEATURE 1 #define FOO_HAS_ANOTHER_FEATURE 1 #endif /* FOO_CONFIG_H */ This is one of the possible rewriting (though he doesn't talk about that in his book). The other approach, used in glib (and is explained in his book), is to use that information to precompute some of the results of those '#define's rather than use the boring #ifdef FOO_HAS_.../#endif mess in the other header files. This at least pays back for installing a config specific header by making the rest of the headers more readable. I do agree that the use of macros in a config.h such as "PACKAGE," "VERSION" and "HAVE_*" is a bad thing since they are named generically. It would be nice if it was possible to make autoconf prepend a package name, for example, to such automatically defined macros. That would at least help alleviate the problem. You can do that yourself sed 's,^#define ,#define FOO_,' config.h foo-config.h I would be loath to changing autoconf to make installing config.h more convenient. The whole philosophy of config.h is that it is used to improve the portablility of the particular package it's generated for, not as a general portability helper. In other words, wanting to install config.h is itself the problem ;-) There is also the problem with installing something that depends on the output of a configure run into $prefix. The proper home for such beasts is $exec_prefix. It would be nice if there was an $(execincludedir) [= $(exec_prefix)/include]. - 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: ifeq/else/endif problem
Patrick Guio [EMAIL PROTECTED] writes: I am trying to insert a conditional part in a Makefile.am in the following way : ## 2-dimensions library libmudfas2d_la_SOURCES = $(MUDSRC) ifeq ($(CXX),cxx) libmudfas2d_la_CXXFLAGS = -ptr mudfas2d -DDIM=2 libmudfas2d_la_LDFLAGS = mudfas2d/*.o -version-info 0:0:0 else libmudfas2d_la_CXXFLAGS = -DDIM=2 libmudfas2d_la_LDFLAGS = -version-info 0:0:0 endif But when running automake I get % automake -a -c --include-deps src/Makefile.am:24: endif without if src/Makefile.am:31: else without if src/Makefile.am:34: endif without if src/Makefile.am:41: else without if src/Makefile.am:44: endif without if Automake has its own conditional, which, unfortunately, share keywords with GNU make conditionals. If you can convert your checks above to automake conditionals, that would be good. In configure.in, do AM_CONDITIONAL(COMPILER_IS_COMPAQ_CXX, [test x"$CXX" = xcxx]) and in Makefile.am, do if COMPILER_IS_COMPAQ_CXX foo else bar endif Otherwise, in case of extreme duress, try this (untested): In configure.in, MK=''; AC_SUBST(MK) And in Makefile.am: @MK@ifeq ... foo @MK@else bar @MK@endif However, you cannot put in automake magic variables (things like foo_SOURCES, foo_LDFLAGS, etc) inside an ifeq/else/endif. Rather, you can, but automake will get extremely confused if you do ;-) - 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: How to install config.h
Simon Richter [EMAIL PROTECTED] writes: On 27 Oct 2000, Mark Galassi wrote: [Installing config.h] But be careful: if any of the C code in the package itself includes your-package-name/config.h you might be in for a nasty surprise: if a version is already installed and a user is compiling a new version from source, that user will pick up the installed .h files which will Even more evil: These files will contain definitions for PACKAGE and VERSION. And unless the configure.in tests are exactly the same, you'll have HAVE_* conflicts. Compare (on Solaris) AC_CHECK_LIB(resolv, inet_aton) #define HAVE_RESOLV 1 AC_CHECK_FUNC(inet_ntoa)#define HAVE_INET_NTOA vs. AC_CHECK_LIB(resolv, inet_aton, RESOLV_LIB=-lresolv) #define HAVE_RESOLV 1 AC_CHECK_FUNC(inet_ntoa) #undef HAVE_INET_NTOA (I know, in "reasonable" circumstances, this example won't really cause problems, even with both config.h being included.) And, then we have the problem of having anything depending on the output of config.status going into $prefix rather than $exec_prefix. - 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: More about dependencies...
Patrick Guio [EMAIL PROTECTED] writes: I refer to my earlier mails about problem with c++ dependencies. I don't know whether this is a bug but I found out why I could not make dependencies tracking working correctly. My code consists of several directories ~ ~/src ~/tests and so on ~/Makefile.am does not contain so much ~/src is a directory with common c++ headers and source codes while ~/tests contains source codes to build and test. When I run automake (-a -c --include-deps --force-missing) 'depcomp' were installed in ~/src and ~/tests but *not* in ~ And there is the problem: when running configure I always got the messages checking dependency style of g++... none checking dependency style of gcc... none until I manually add a ~/depcomp Then checking dependency style of g++... gcc checking dependency style of gcc... gcc Why is a ~/depcomp necessary in ~/ since I don't have any code there? Actually it is needed only there, and not in the source directories. You just need one copy of the script per tree. 'automake' appears to be buggy. - 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: dependencies in c++
Patrick Guio [EMAIL PROTECTED] writes: On 19 Oct 2000, Alexandre Oliva wrote: On Oct 19, 2000, Patrick Guio [EMAIL PROTECTED] wrote: I really have problems to get the dependencies stuff to work correctly. I can see that some depcomp files are installed in my subdirectories but if I touch a .h file the stuff is not rebuilt. Which compiler are you using? The new dependency-tracking code in automake only enables dependency tracking by default if the compiler can generate dependencies as a side-effect of compilation. In other cases, you have enable it explicitly. Run `configure --help' for the options. I use mainly g++ but also cxx and KCC. When running % configure --enable-dependency-tracking I get the following: checking whether the C++ compiler works... yes checking dependency style of g++... (cached) none Does it has something to do with my problem? I use autoconf/automake/libtool which I get from cvs and the last I have successfully compiled is less than 1 month. Did you remove config.cache before rerunning the configure? 'config.cache' may have the results of a previous run where you didn't --enable-dependency-tracking, or it may have had the results for a different compiler. - 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: [PATCH] compare header files before installing
Alexandre Oliva [EMAIL PROTECTED] writes: On Oct 16, 2000, Akim Demaille [EMAIL PROTECTED] wrote: This patch seems OK to me, but I'd appreciate if Alexandre, Tom, Pavel or Jim could confirm it's OK. I have mixed feelings about this. At first, it may sound nice to not touch pre-existing files. However, think of someone that uses the timestamp to decide whether a certain file is part of the newly installed package or just some remnant from an old release that can now be removed... One approach would be to use $(INSTALL_HEADER) which defaults to $(INSTALL_DATA), and allow users to specify a special installer if they choose. Of course, it would be nice if 'install' in fileutils could be extended to provide a --only-if-change option. Usage would be something like make INSTALL_HEADER='install --only-if-change' install - 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
