bug#20186: Failure to create directory during info-building phase of make distcheck
On Tue, 24 Mar 2015, James Youngman wrote: The timestamps look OK to me: ... Perhaps the cause is this rule, though: dblocation.texi: ../locate/dblocation.texi cp ../locate/dblocation.texi $@ This will clearly update the mtime of dblocation.texi. Hi James, indeed. You could use the modified rule dblocation.texi: ../locate/dblocation.texi $(LN_S) ../locate/dblocation.texi $@ where $(LN_S) is 'ln -s' on systems with working symlinks or otherwise one of 'ln' or 'cp'. I assume your Makefile.in already contains LN_S = @LN_S@ otherwise you should add AC_PROG_LN_S to your configure.ac. I assume 'make distcheck' will never run on systems without working symlinks so this should be OK. Regards Peter
bug#20186: Failure to create directory during info-building phase of make distcheck
On Tue, 24 Mar 2015, James Youngman wrote: I'm seeing a failure of make distcheck which I think is caused by the fact that Automake 1.14.1's rule for .texi.info is trying to create a backup directory in a read-only directory: Hi James, the .info file in the read-only directory should not be older than the .texi file (and other dependencies), thus the rule for .texi.info should never be used during make distcheck. Something wrong with your timestamps and or filesystem? Regards Peter Breitenlohner p...@mppmu.mpg.de
Re: [PATCH 09/10] objc, objc++: add stress test
On Tue, 1 May 2012, Stefano Lattarini wrote:
From: Peter Breitenlohner p...@mppmu.mpg.de
* t/objc-megademo.sh: New test, trying out a package using all
of C, C++, Objective C and Objective C++ at the same time.
* t/list-of-tests.mk: Add it.
Hi Stefano,
I have just noticed that in the source file foo.h
+## Library Sources.
+
+cat foo.h 'END'
+#ifndef FOO_H
+#define FOO_H
+
+#ifdef __cplusplus
+#include iostream
+extern C {
+#else
+#include stdio.h
+#endif
+
+void world_c (void);
+void world_objcxx (void);
this declaration of world_objcxx is unused (left over from an earlier
demo version) and should be removed.
Regards
Peter Breitenlohner p...@mppmu.mpg.de
[PATCH 2/6] objc: test global, per-target, and user flags
* t/objc-flags.sh: New test. Signed-off-by: Peter Breitenlohner p...@mppmu.mpg.de --- t/objc-flags.sh | 73 +++ 1 files changed, 73 insertions(+), 0 deletions(-) create mode 100755 t/objc-flags.sh diff --git a/t/objc-flags.sh b/t/objc-flags.sh new file mode 100755 index 000..e10faf5 --- /dev/null +++ b/t/objc-flags.sh @@ -0,0 +1,73 @@ +#! /bin/sh +# Copyright (C) 2012 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. + +# Check that $(OBJCFLAGS) takes precedence over both $(AM_OBJCFLAGS) and +# $(foo_OBJCFLAGS). + +required=cc +. ./defs || Exit 1 + +cat fake-objc 'END' +#!/bin/sh +echo $* objcflags.list +END +chmod a+x fake-objc + +# Remove ObjC from the environment, so that it won't interfere +# with 'make -e' below. +unset OBJC || : + +cat configure.ac 'END' +AC_SUBST([CC], [false]) +# Simulate presence of ObjC using our fake-objc script. +AC_SUBST([OBJC], ['$(abs_top_srcdir)'/fake-objc]) +AC_OUTPUT +END + +cat Makefile.am 'END' +AUTOMAKE_OPTIONS = no-dependencies +bin_PROGRAMS = foo bar +foo_SOURCES = main.c foo.m +bar_SOURCES = main.c bar.m +AM_OBJCFLAGS = __am_flags__ +bar_OBJCFLAGS = __bar_flags__ +END + +$ACLOCAL +$AUTOMAKE -a + +grep '\$(OBJCFLAGS).*\$(bar_OBJCFLAGS)' Makefile.in Exit 1 +grep '\$(OBJCFLAGS).*\$(AM_OBJCFLAGS)' Makefile.in Exit 1 + +: foo.m +: bar.m + +$AUTOCONF +./configure +env OBJCFLAGS=__user_flags__ $MAKE -e foo.o bar-bar.o + +cat objcflags.list + +grep 'foo.o' objcflags.list foo.o +grep 'bar-bar.o' objcflags.list bar-bar.o + +cat foo.o +cat bar-bar.o + +grep '__am_flags__.*__user_flags__' foo.o +grep '__bar_flags__.*__user_flags__' bar-bar.o + +: -- 1.7.3.1
[PATCH 3/6] objc++: test automatic dependency tracking
* t/objcxx-deps.sh: New test.
Signed-off-by: Peter Breitenlohner p...@mppmu.mpg.de
---
t/objcxx-deps.sh | 46 ++
1 files changed, 46 insertions(+), 0 deletions(-)
create mode 100755 t/objcxx-deps.sh
diff --git a/t/objcxx-deps.sh b/t/objcxx-deps.sh
new file mode 100755
index 000..f9228de
--- /dev/null
+++ b/t/objcxx-deps.sh
@@ -0,0 +1,46 @@
+#! /bin/sh
+# Copyright (C) 2012 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+# Make sure dependency tracking works for ObjC++.
+
+. ./defs || Exit 1
+
+cat configure.ac 'END'
+# Objective C++ requires Autoconf 2.65 (2009-11-21)
+AC_PREREQ([2.65])
+_AM_DEPENDENCIES([OBJCXX])
+AC_SUBST([OBJCXX])
+END
+
+cat Makefile.am 'END'
+bin_PROGRAMS = convert
+convert_SOURCES = convert.mm
+END
+
+$ACLOCAL || {
+ if test $? -eq 63; then
+exit 77
+ else
+exit $?
+ fi
+}
+
+$AUTOMAKE
+
+num=`grep depcomp Makefile.in | wc -l`
+test $num -gt 1
+
+:
--
1.7.3.1
[PATCH 1/6] objc++: test global, per-target, and user flags
* t/objcxx-flags.sh: New test.
Signed-off-by: Peter Breitenlohner p...@mppmu.mpg.de
---
t/objcxx-flags.sh | 82 +
1 files changed, 82 insertions(+), 0 deletions(-)
create mode 100755 t/objcxx-flags.sh
diff --git a/t/objcxx-flags.sh b/t/objcxx-flags.sh
new file mode 100755
index 000..0925b41
--- /dev/null
+++ b/t/objcxx-flags.sh
@@ -0,0 +1,82 @@
+#! /bin/sh
+# Copyright (C) 2012 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+# Check that $(OBJCXXFLAGS) takes precedence over both $(AM_OBJCXXFLAGS) and
+# $(foo_OBJCXXFLAGS).
+
+required=cc
+. ./defs || Exit 1
+
+cat fake-objcxx 'END'
+#!/bin/sh
+echo $* objcxxflags.list
+END
+chmod a+x fake-objcxx
+
+# Remove ObjC++ from the environment, so that it won't interfere
+# with 'make -e' below.
+unset OBJCXX || :
+
+cat configure.ac 'END'
+# Objective C++ requires Autoconf 2.65 (2009-11-21)
+AC_PREREQ([2.65])
+AC_SUBST([CC], [false])
+# Simulate presence of ObjC++ using our fake-objcxx script.
+AC_SUBST([OBJCXX], ['$(abs_top_srcdir)'/fake-objcxx])
+AC_OUTPUT
+END
+
+cat Makefile.am 'END'
+AUTOMAKE_OPTIONS = no-dependencies
+bin_PROGRAMS = foo bar
+foo_SOURCES = main.c foo.mm
+bar_SOURCES = main.c bar.mm
+AM_OBJCXXFLAGS = __am_flags__
+bar_OBJCXXFLAGS = __bar_flags__
+END
+
+$ACLOCAL || {
+ if test $? -eq 63; then
+exit 77
+ else
+exit $?
+ fi
+}
+
+$AUTOMAKE -a
+
+grep '\$(OBJCXXFLAGS).*\$(bar_OBJCXXFLAGS)' Makefile.in Exit 1
+grep '\$(OBJCXXFLAGS).*\$(AM_OBJCXXFLAGS)' Makefile.in Exit 1
+
+: foo.mm
+: bar.mm
+
+$AUTOCONF
+./configure
+env OBJCXXFLAGS=__user_flags__ $MAKE -e foo.o bar-bar.o
+
+cat objcxxflags.list
+
+grep 'foo.o' objcxxflags.list foo.o
+grep 'bar-bar.o' objcxxflags.list bar-bar.o
+
+cat foo.o
+cat bar-bar.o
+
+grep '__am_flags__.*__user_flags__' foo.o
+grep '__bar_flags__.*__user_flags__' bar-bar.o
+
+:
--
1.7.3.1
[PATCH 5/6] objc++: test more automatic dependency tracking
* t/objcxx-deps2.sh: New test.
Signed-off-by: Peter Breitenlohner p...@mppmu.mpg.de
---
t/objcxx-deps2.sh | 58 +
1 files changed, 58 insertions(+), 0 deletions(-)
create mode 100755 t/objcxx-deps2.sh
diff --git a/t/objcxx-deps2.sh b/t/objcxx-deps2.sh
new file mode 100755
index 000..8ca1e72
--- /dev/null
+++ b/t/objcxx-deps2.sh
@@ -0,0 +1,58 @@
+#! /bin/sh
+# Copyright (C) 2012 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+# Make sure dependency tracking works for ObjC++.
+
+required=g++
+. ./defs || Exit 1
+
+cat configure.ac 'END'
+# Objective C++ requires Autoconf 2.65 (2009-11-21)
+AC_PREREQ([2.65])
+AC_PROG_OBJCXX([g++])
+AC_OUTPUT
+END
+
+cat Makefile.am 'END'
+bin_PROGRAMS = convert
+convert_SOURCES = convert.mm
+END
+
+$ACLOCAL || {
+ if test $? -eq 63; then
+exit 77
+ else
+exit $?
+ fi
+}
+
+$AUTOCONF
+$AUTOMAKE
+./configure stdout || exit 77 # in case g++ does not support ObjC++
+cat stdout
+
+# Configure must be checking the dependency style of g++ ...
+grep 'dependency style of g++' stdout filt
+cat filt
+
+# ... only once.
+test `wc -l filt` = 1
+
+# Accept any outcome but 'none'
+# (at the time of writing it should be gcc or gcc3).
+grep -v none filt
+
+:
--
1.7.3.1
[PATCH 6/6] objc: test more automatic dependency tracking
* t/objc-deps2.sh: New test. Signed-off-by: Peter Breitenlohner p...@mppmu.mpg.de --- t/objc-deps2.sh | 49 + 1 files changed, 49 insertions(+), 0 deletions(-) create mode 100755 t/objc-deps2.sh diff --git a/t/objc-deps2.sh b/t/objc-deps2.sh new file mode 100755 index 000..9b2dba8 --- /dev/null +++ b/t/objc-deps2.sh @@ -0,0 +1,49 @@ +#! /bin/sh +# Copyright (C) 2012 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. + +# Make sure dependency tracking works for ObjC. + +required=gcc +. ./defs || Exit 1 + +cat configure.ac 'END' +AC_PROG_OBJC([gcc]) +AC_OUTPUT +END + +cat Makefile.am 'END' +bin_PROGRAMS = convert +convert_SOURCES = convert.m +END + +$ACLOCAL +$AUTOCONF +$AUTOMAKE +./configure stdout || exit 77 # in case gcc does not support ObjC +cat stdout + +# Configure must be checking the dependency style of gcc ... +grep 'dependency style of gcc' stdout filt +cat filt + +# ... only once. +test `wc -l filt` = 1 + +# Accept any outcome but 'none' +# (at the time of writing it should be gcc or gcc3). +grep -v none filt + +: -- 1.7.3.1
Re: [PATCH 1/5] objc++: initial support for Objective C++
On Mon, 30 Apr 2012, Stefano Lattarini wrote: Unfortunately, this patch breaks automake with older autoconfs (e.g., 2.62), even when the Objective C++ is not used. For example: ... This is due to the unconditional use of 'AC_PROG_OBJCXX' in AM_INIT_AUTOMAKE. I've squashed in the diff below, that solves the issue. Hi Stefano, Oops. Initially in 2009 the idea was to require Autoconf 2.65, but with this workaround there is no need to do that. You should, however, add this to the list of things to clean up once Automake requires Autoconf = 2.65 (assuming there is such a list). Regards Peter
Re: [PATCH 5/6] objc++: test more automatic dependency tracking
On Mon, 30 Apr 2012, Stefano Lattarini wrote: Hi Peter, thanks for the patch. However, I've opted for a more semantic approach, implemented by the attached test case. Hi Stefano, fine with me (except for a typo s/autocon,/autoconf,/. But please note that these tests will fail if gcc/g++ does not support Objective C/C++ (unfortunately the are no special front ends). Regards Peter Breitenlohner p...@mppmu.mpg.de
Re: [PATCH 5/5] objc++: add first tests
On Fri, 27 Apr 2012, Stefano Lattarini wrote:
diff --git a/t/objcxx-demo.sh b/t/objcxx-demo.sh
new file mode 100755
index 000..7af089f
--- /dev/null
+++ b/t/objcxx-demo.sh
@@ -0,0 +1,61 @@
+#! /bin/sh
+# Demo package using Objective C++ and doing distcheck.
+
+required='cc c++'
+. ./defs || Exit 1
+
+cat configure.ac 'END'
+AC_PROG_CC
+AC_PROG_CXX
+AC_PROG_OBJC
+AC_PROG_OBJCXX
Here, we should ensure the test is skipped if any of AC_PROG_OBJC or
AC_PROG_OBJCXX is undefined (because the autoconf version being used
is too old, i.e., 2.66 if I'm not mistaken). That can be done in
a follow-up patch though.
According to my info (from 2009) and the Autoconf-2.68 NEWS it is 2.65.
How to do such a test when Automake already requires 2.68.
+AC_CONFIG_HEADERS([config.h])
+AC_OUTPUT
+END
+
+cat Makefile.am 'END'
+bin_PROGRAMS = play
+play_SOURCES = play.c playxx.cxx playobjc.m playobjcxx.mm
+END
+
+cat play.c 'END'
+#include config.h
+#include stdio.h
+int main (void)
+{
+ printf(Hello, world! ( PACKAGE_STRING )\n);
+ return 0;
+}
+END
+
+echo '//' playxx.cxx
+
+echo '/* */' playobjc.m
+
+echo '//' playobjcxx.mm
+
Rather than having dummy files, I'd like to have files with real content
here, to ensure better similarity with real-world usage.
No problem.
Extra points if you can make the content of the '.m' file valid only as ObjC
(not as ObjC++, C, nor C++) and the content of the '.mm' file valid only as
ObjC++ (not as ObjC C, nor C++), to ensure the correct compiler is being used
based on the file extension.
I'll try, but that might go beyong my knowledge of ObjC/ObjC++.
I am doing all this for the TeX Live build system that contains two programs
where the Mac OS X versions use .m and .mm files. Until now the .mm file
is invoked via a C++ wrapper and put into a separate library libxetexmm.a
compiled with libxetexmm_a_CXXFLAGS=-ObjC++ -- what a kludge.
Even more kudos if you can make the all the functions defined in all of
'playxx.cxx', 'playobjc.m' and 'playobjcxx.mm' actually invoked by the
'main()' function.
Should be simple enough with main() in playobjcxx.mm [or the (Obj)C(++)
functions invoked indirectly via C functions in the respective (Obj)C(++)
files], as long as you don't require that the program actually runs and does
anything useful.
Also, for a better coverage, I'd like to have two more tests (in new files):
- one that tests automatic dependency tracking for '.mm' files
(t/objcxx-deps.sh)
- one that checks the use of global compile flags '$(AM_OBJCXXFLAGS)',
per-taget compile flags '$(foo_OBJCXXFLAGS)', that the latter takes
precedence on the former, and that user-specified compile flags
'$(OBJCXXFLAGS)' take precedence over both
(objcxx-flags.sh)
Similar tests should also be added for the Objective C case; but that's material
for a follow-up patch.
I think part of that could be done by extending existing tests (ext2.sh,
specflg-dummy.sh, and/or specflg2.sh), the rest by new tests inspired by
those. Will have a look.
Regards
Peter Breitenlohner p...@mppmu.mpg.de
bug#11346: automake-1.12 - one test fails (due to truncated timestamp)
On Thu, 26 Apr 2012, Stefano Lattarini wrote: Good idea. Can you confirm that the attached patch solves your problem? Hi Stefano, it does indeed. BTW: The Copyright-paperwork-exempt: yes should be unnecessary because you should still have the paperwork from the ObjC++ integration. Regards Peter
bug#11346: automake-1.12 - one test fails (due to truncated timestamp)
On Thu, 26 Apr 2012, Stefano Lattarini wrote: because you should still have the paperwork from the ObjC++ integration. I wasn't involved in the project yet back then, so I wasn't aware you had the paperwork in place already. Now I am :-) Hi Stefano, and the whole ObjC++ integration (one of two reasons I was waiting for 1.12) somehow got lost. I still have the old patches 0001-2009-07-22-Support-for-Objective-C.patch from 2009-07-22 etc, but could also apply them to the current git version and send you these. I may, however, have problem to modernize the test cases. Regards Peter
[SPAM] Re: ObjC++ integration (was: Re: bug#11346: automake-1.12 - one test fails (due to truncated timestamp)
On Thu, 26 Apr 2012, Stefano Lattarini wrote:
On 04/26/2012 01:56 PM, Peter Breitenlohner wrote:
but could also apply them to the current git version and send you these.
Please do. If they are not-invasive, they could appear in 1.12.1.
Hi Stefano,
attached are six patches. The first four are against the current git:
0001-Support-for-Objective-C.patch - the code
0002-Support-for-Objective-C.patch - the manual
0003-Support-for-Objective-C.patch - modified tests
0004-Support-for-Objective-C.patch - announcement
I may, however, have problem to modernize the test cases.
If you experience problems, just prod us on the list; I'd be very happy to
help with this.
The last two patches are old and contain complete old-style test cases:
-Support-for-Objective-C.patch - two new ObjC++ specific tests (from 2009)
0003-A-complete-demo-package-using-ObjC-and-distcheck.patch - an additional
test from 2009 (Ralf Wildenhues had asked for such a complete package).
Thanks, and sorry for the confusion,
No problem.
Regards
Peter Breitenlohner p...@mppmu.mpg.deFrom 3f7c44e5ed1534f8ab0c20918728572c36bea4fa Mon Sep 17 00:00:00 2001
From: Peter Breitenlohner p...@mppmu.mpg.de
Date: Thu, 26 Apr 2012 15:01:23 +0200
Subject: [PATCH 1/4] Support for Objective C++
* automake.in: Register new language.
(lang_objcxx_rewrite): New subroutine.
(resolve_linker): Add OBJCXXLINK.
(%_am_macro_for_cond): Add am__fastdepOBJCXX and AC_PROG_OBJCXX.
(%-ac_macro_for_var): Add OBJCXX and OBJCXXFLAGS.
* m4/depend.m4 (_AM_DEPENDENCIES): Add OBJCXX.
* m4/init.m4 (AM_INIT_AUTOMAKE): Add AC_PROG_OBJCXX hook.
Signed-off-by: Peter Breitenlohner p...@mppmu.mpg.de
---
automake.in | 29 +++--
lib/Automake/Variable.pm |2 ++
m4/depend.m4 |5 +++--
m4/init.m4 |6 +-
4 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/automake.in b/automake.in
index 43a7ba6..c8c5b01 100644
--- a/automake.in
+++ b/automake.in
@@ -760,6 +760,24 @@ register_language ('name' = 'objc',
'pure' = 1,
'extensions' = ['.m']);
+# Objective C++.
+register_language ('name' = 'objcxx',
+ 'Name' = 'Objective C++',
+ 'config_vars' = ['OBJCXX'],
+ 'linker' = 'OBJCXXLINK',
+ 'link' = '$(OBJCXXLD) $(AM_OBJCXXFLAGS) $(OBJCXXFLAGS)
$(AM_LDFLAGS) $(LDFLAGS) -o $@',
+ 'autodep' = 'OBJCXX',
+ 'flags' = ['OBJCXXFLAGS', 'CPPFLAGS'],
+ 'compile' = '$(OBJCXX) $(DEFS) $(DEFAULT_INCLUDES)
$(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_OBJCXXFLAGS) $(OBJCXXFLAGS)',
+ 'ccer' = 'OBJCXX',
+ 'compiler' = 'OBJCXXCOMPILE',
+ 'compile_flag' = '-c',
+ 'output_flag' = '-o',
+ 'lder' = 'OBJCXXLD',
+ 'ld' = '$(OBJCXX)',
+ 'pure' = 1,
+ 'extensions' = ['.mm']);
+
# Unified Parallel C.
register_language ('name' = 'upc',
'Name' = 'Unified Parallel C',
@@ -5793,6 +5811,12 @@ sub lang_objc_rewrite
return lang_sub_obj;
}
+# Rewrite a single Objective C++ file.
+sub lang_objcxx_rewrite
+{
+return lang_sub_obj;
+}
+
# Rewrite a single Unified Parallel C file.
sub lang_upc_rewrite
{
@@ -6057,7 +6081,7 @@ sub resolve_linker
{
my (%linkers) = @_;
-foreach my $l (qw(GCJLINK CXXLINK F77LINK FCLINK OBJCLINK UPCLINK))
+foreach my $l (qw(GCJLINK OBJCXXLINK CXXLINK F77LINK FCLINK OBJCLINK
UPCLINK))
{
return $l if defined $linkers{$l};
}
@@ -6245,13 +6269,14 @@ sub make_conditional_string ($$)
my %_am_macro_for_cond =
(
AMDEP = one of the compiler tests\n
- . AC_PROG_CC, AC_PROG_CXX, AC_PROG_CXX, AC_PROG_OBJC,\n
+ . AC_PROG_CC, AC_PROG_CXX, AC_PROG_OBJC, AC_PROG_OBJCXX,\n
. AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC,
am__fastdepCC = 'AC_PROG_CC',
am__fastdepCCAS = 'AM_PROG_AS',
am__fastdepCXX = 'AC_PROG_CXX',
am__fastdepGCJ = 'AM_PROG_GCJ',
am__fastdepOBJC = 'AC_PROG_OBJC',
+ am__fastdepOBJCXX = 'AC_PROG_OBJCXX',
am__fastdepUPC = 'AM_PROG_UPC'
);
diff --git a/lib/Automake/Variable.pm b/lib/Automake/Variable.pm
index 4d346f0..d4d230f 100644
--- a/lib/Automake/Variable.pm
+++ b/lib/Automake/Variable.pm
@@ -185,6 +185,8 @@ my %_ac_macro_for_var =
FCFLAGS = 'AC_PROG_FC',
OBJC = 'AC_PROG_OBJC',
OBJCFLAGS = 'AC_PROG_OBJC',
+ OBJCXX = 'AC_PROG_OBJCXX',
+ OBJCXXFLAGS = 'AC_PROG_OBJCXX',
RANLIB = 'AC_PROG_RANLIB',
UPC = 'AM_PROG_UPC',
UPCFLAGS = 'AM_PROG_UPC',
diff --git a/m4/depend.m4 b/m4/depend.m4
index 8d7adf6..cee3199 100644
--- a/m4/depend.m4
+++ b/m4/depend.m4
@@ -5,7 +5,7 @@
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
-# serial 16
+# serial 17
# There are a few dirty hacks
Re: bug#11089: LINK determination
On Tue, 27 Mar 2012, Stefano Lattarini wrote: [Adding automake-patches] Reference: http://debbugs.gnu.org/11089 On Sun, Mar 25, 2012 at 11:20 AM, Stefano Lattarini wrote: I'd describe this as an automake limitation; not sure if it's worth fixing (since yours is not a common use case, and the issue you're facing has a simple-enough workaround, as you've already found out); but it would be worth documenting IMHO. this situation is actually more common than one might think. E.g., the Makefile.am for gnuplot-4.6.0/src/ contains gnuplot_SOURCES = alloc.c ETC. if BUILD_WXWIDGETS gnuplot_SOURCES += wxterminal/wxt_gui.cpp endif but that actually ought to be gnuplot_SOURCES = alloc.c ETC. if BUILD_WXWIDGETS gnuplot_SOURCES += wxterminal/wxt_gui.cpp gnuplot_LINK = $(CXXLINK) else gnuplot_LINK = $(LINK) endif On a second thought, I've been unable to find a way to document Jason's workaround that doesn't sound cumbersome and clumsy; so maybe it's better to just drop this documentation change. Still, having a test case verifying that such a workaround actually works is still worthwhile and easy to do. This is what the attached patch does. I will push it this evening or tomorrow if there is no objection. the workaround described earlier in this thread and used in the test case: if HAVE_CXX foo_LINK = $(CXXLINK) else foo_LINK = $(LINK) endif works nicely and is simple enough when not using libtool libraries. When linking foo with (installed or uninstalled) libtool libraries, the default definition of foo_LINK generated by Automake would be something like foo_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=link $(CXXLD) $(foo_CXXFLAGS) $(CXXFLAGS) \ $(foo_LDFLAGS) $(LDFLAGS) -o $@ and a more elaborate workaround is needed. What is the best way to handle this situation? An additional test case? Regards Peter Breitenlohner p...@mppmu.mpg.de
Re: bug#11089: LINK determination
On Tue, 27 Mar 2012, Stefano Lattarini wrote: [Adding automake-patches] Reference: http://debbugs.gnu.org/11089 On Sun, Mar 25, 2012 at 11:20 AM, Stefano Lattarini wrote: I'd describe this as an automake limitation; not sure if it's worth fixing (since yours is not a common use case, and the issue you're facing has a simple-enough workaround, as you've already found out); but it would be worth documenting IMHO. this situation is actually more common than one might think. E.g., the Makefile.am for gnuplot-4.6.0/src/ contains gnuplot_SOURCES = alloc.c ETC. if BUILD_WXWIDGETS gnuplot_SOURCES += wxterminal/wxt_gui.cpp endif but that actually ought to be gnuplot_SOURCES = alloc.c ETC. if BUILD_WXWIDGETS gnuplot_SOURCES += wxterminal/wxt_gui.cpp gnuplot_LINK = $(CXXLINK) else gnuplot_LINK = $(LINK) endif On a second thought, I've been unable to find a way to document Jason's workaround that doesn't sound cumbersome and clumsy; so maybe it's better to just drop this documentation change. Still, having a test case verifying that such a workaround actually works is still worthwhile and easy to do. This is what the attached patch does. I will push it this evening or tomorrow if there is no objection. the workaround described earlier in this thread and used in the test case: if HAVE_CXX foo_LINK = $(CXXLINK) else foo_LINK = $(LINK) endif works nicely and is simple enough when not using libtool libraries. When linking foo with (installed or uninstalled) libtool libraries, the default definition of foo_LINK generated by Automake would be something like foo_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=link $(CXXLD) $(foo_CXXFLAGS) $(CXXFLAGS) \ $(foo_LDFLAGS) $(LDFLAGS) -o $@ and a more elaborate workaround is needed. What is the best way to handle this situation? An additional test case? Regards Peter Breitenlohner p...@mppmu.mpg.de
bug#10997: pkglibexecdir is unconditionally created when make install
On Mon, 12 Mar 2012, Stefano Lattarini wrote: On 03/12/2012 05:55 AM, Daiki Ueno wrote: I got a bug report for my package, which conditionally installs some scripts into pkglibexecdir like this: if ENABLE_FOO pkglibexec_SCRIPTS = bar endif where pkglibexec* is not referred outside of if...endif. When make install, automake creates pkglibexecdir even when ENABLE_FOO is false. I'm attaching a prove which demonstrates the behavior. I agree it would be nice to avoid creating directories that are not actually needed; still, this is a low-priority bug, and I'm not yet sure how difficult it would be to fix. For the moment, I've committed (in your name) the test case you've sent us (with minor tweakings), so that the bug will at least remain exposed in the testsuite. Attached is the patch I've pushed (to maint). Fixing this particular case might be fine, but please watch out. In the quite similar (unconditional) case pkglibexec_SCRIPTS = one might actually expect that that $(pkglibexecdir) is created unconditionally. (Perhaps because 'install-exec-local' or 'install-data-local' wants to install some files into that directory.) In the TeX Live build system we actually use something quite analogous: nodist_bin_SCRIPTS = texmfdir = $(datarootdir)/texmf/scripts/xindy nodist_texmf_SCRIPTS = texindy.pl xindy.pl install-data-hook: install-perl-links where 'install-perl-links' installs in $(bindir) the symbolic links 'texindy' and 'xindy' pointing to the respective perl scripts in $(texmfdir). To summarize: 'nodist_bin_SCRIPTS =' is an extremely convenient way to ensure that $(bindir) -- or rather $(DESTDIR)$(bindir) -- exists. Regards Peter Breitenlohner p...@mppmu.mpg.de
Re: bug#10997: pkglibexecdir is unconditionally created when make install
On Mon, 12 Mar 2012, Stefano Lattarini wrote: On 03/12/2012 05:55 AM, Daiki Ueno wrote: I got a bug report for my package, which conditionally installs some scripts into pkglibexecdir like this: if ENABLE_FOO pkglibexec_SCRIPTS = bar endif where pkglibexec* is not referred outside of if...endif. When make install, automake creates pkglibexecdir even when ENABLE_FOO is false. I'm attaching a prove which demonstrates the behavior. I agree it would be nice to avoid creating directories that are not actually needed; still, this is a low-priority bug, and I'm not yet sure how difficult it would be to fix. For the moment, I've committed (in your name) the test case you've sent us (with minor tweakings), so that the bug will at least remain exposed in the testsuite. Attached is the patch I've pushed (to maint). Fixing this particular case might be fine, but please watch out. In the quite similar (unconditional) case pkglibexec_SCRIPTS = one might actually expect that that $(pkglibexecdir) is created unconditionally. (Perhaps because 'install-exec-local' or 'install-data-local' wants to install some files into that directory.) In the TeX Live build system we actually use something quite analogous: nodist_bin_SCRIPTS = texmfdir = $(datarootdir)/texmf/scripts/xindy nodist_texmf_SCRIPTS = texindy.pl xindy.pl install-data-hook: install-perl-links where 'install-perl-links' installs in $(bindir) the symbolic links 'texindy' and 'xindy' pointing to the respective perl scripts in $(texmfdir). To summarize: 'nodist_bin_SCRIPTS =' is an extremely convenient way to ensure that $(bindir) -- or rather $(DESTDIR)$(bindir) -- exists. Regards Peter Breitenlohner p...@mppmu.mpg.de
bug#8969: improve synchronization between examples in the manual and test cases
On Fri, 1 Jul 2011, Stefano Lattarini wrote: Oops, one of the amhello tests has an unecessary requirement (copy paste blunder). Consider the following squashed in: diff --git a/tests/amhello-binpkg.test b/tests/amhello-binpkg.test index 8da3495..47add73 100755 --- a/tests/amhello-binpkg.test +++ b/tests/amhello-binpkg.test @@ -17,7 +17,6 @@ # Document an example from the manual about the `amhello' package: # using DESDIR to build simple, no-frills binary packages. Hi Stefano, could this be a typo (DESDIR vs DESTDIR)? Regards Peter Breitenlohner p...@mppmu.mpg.de
Re: bug#8969: improve synchronization between examples in the manual and test cases
On Fri, 1 Jul 2011, Stefano Lattarini wrote: Oops, one of the amhello tests has an unecessary requirement (copy paste blunder). Consider the following squashed in: diff --git a/tests/amhello-binpkg.test b/tests/amhello-binpkg.test index 8da3495..47add73 100755 --- a/tests/amhello-binpkg.test +++ b/tests/amhello-binpkg.test @@ -17,7 +17,6 @@ # Document an example from the manual about the `amhello' package: # using DESDIR to build simple, no-frills binary packages. Hi Stefano, could this be a typo (DESDIR vs DESTDIR)? Regards Peter Breitenlohner p...@mppmu.mpg.de
bug#8718: error when using nested conditionals
On Fri, 10 Jun 2011, Stefano Lattarini wrote:
Nope, it gets the information from the fact each AM_CONDITIONAL invocation
does this:
AC_CONFIG_COMMANDS_PRE(
[if test -z ${$1_TRUE} test -z ${$1_FALSE}; then
AC_MSG_ERROR([[conditional $1 was never defined.
Usually this means the macro was only invoked conditionally.]])
fi])])
Hi Stefano, Bruno,
how about the following alternative (for all conditionals, or just for some
of them, e.g., those under the regime of AM_IGNORE_UNDEFINED_CONDITIONALS):
Replace the AC_MSG_ERROR() above by a warning and set both $1_TRUE and
$1_FALSE to something that, when not hidden in a false branch of the
Makefile, (1) triggers a make syntax error, and (2) contains sufficient info
to deduce the cause for that error.
That way there is a warning from configure (often overlooked and/or
ignored), but an error from make only if that conditional is actually
needed.
Regards
Peter
bug#7833: automake uses two different values for DejaGNU srcdir
On Fri, 14 Jan 2011, Ralf Wildenhues wrote: Through testing I found out again that DejaGNU does not cope with white space in absolute directory names anyway, regardless of srcdir being relative or absolute. That obviates my first point. Remains only the fairly minor src+build-tree relocatability point. Hi Ralf, I remember a problem with gcc's 'make check' that could be related. Some tests failed when `pwd -L` was different from `pwd -P`, presumably due to the two different srcdir's. I could avoid this problem by first doing 'cd `pwd -P`'. Regards Peter Breitenlohner p...@mppmu.mpg.de
Re: [PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef
On Fri, 4 Dec 2009, Ralf Wildenhues wrote: One involved tool is perl: perl -e 'use File::stat; print (stat(README)-mtime . \n);' Hi Ralf, all my tests are for x86_64-linux (however, the utilities are 32Bit ones) on a jfs partition (I think ext2 doesn't have subsecond time stamps). ~ ls -l --fu README -rw-r--r-- 1 peb THEORY 0 2009-12-07 14:15:16.791586449 +0100 README ~ perl -e 'use File::stat; print (stat(README)-mtime . \n);' 1260191716 ~ date -r README +%s 1260191716 This is perl, v5.10.0 built for ix86-linux-gnu touch (GNU coreutils) 7.4 Another is the shell/test, and ls: Create two files with same-second but different sub-second time stamps (try until this succeeds): echo stamp file1 echo stamp file2 ls -l --full-time file? ~ echo stamp file1;sleep 0.5; echo stamp file2; ls -l --fu file? -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:04.460965546 +0100 file1 -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:04.964956156 +0100 file2 then test 'test' and 'ls': if test file2 -nt file1; then echo shell test uses sub-second; fi if /usr/bin/test file2 -nt file1; then echo /usr/bin/test uses sub-second; fi set X `ls -Lt file1 file2` if test $3 = file1; then echo ls uses sub-second; fi ~ if test file2 -nt file1; then echo shell test uses sub-second else echo no; fi no ~ if /bin/test file2 -nt file1; then echo /bin/test uses sub-second; else echo no; fi /bin/test uses sub-second ~ set X `ls -Lt file1 file2` ~ if test $3 = file1; then echo ls uses sub-second; else echo no; fi ls uses sub-second For completeness let's also test 'make': echo 'file1: file2; echo make uses sub-second' Makefile make ~ echo 'file1: file2; echo make uses sub-second' Makefile ~ make echo make uses sub-second make uses sub-second and whether 'touch -r' can generate sub-second stamps: : foo touch -r foo bar ls -l --full-time foo bar ~ touch -r file2 file3; cp -p file2 file4; ls -l --full-time file? -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:04.460965546 +0100 file1 -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:04.964956156 +0100 file2 -rw-r--r-- 1 peb THEORY 0 2009-12-07 14:20:05.0 +0100 file3 -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:05.0 +0100 file4 As I knew already from trying to understand a similar problem, 'cp -p' and 'touch -r' both round sub-seconds, whereas tar and rsync truncate them. This shows that the second autoconf did not update configure. Can you post, for this same build, also ls -lrt --fu autom4te.cache -rw-r--r-- 1 peb THEORY 66570 2009-12-04 11:57:00.858053547 +0100 output.0 -rw-r--r-- 1 peb THEORY 66570 2009-12-04 11:57:01.062638375 +0100 output.1 -rw-r--r-- 1 peb THEORY 66570 2009-12-04 11:57:01.505099509 +0100 output.2 -rw-r--r-- 1 peb THEORY 11851 2009-12-04 11:57:01.650015678 +0100 requests -rw-r--r-- 1 peb THEORY 32184 2009-12-04 11:57:00.858053547 +0100 traces.0 -rw-r--r-- 1 peb THEORY 14302 2009-12-04 11:57:01.062638375 +0100 traces.1 -rw-r--r-- 1 peb THEORY 32257 2009-12-04 11:57:01.505099509 +0100 traces.2 Let's see if your data confirms this. I just tried out my Cygwin install: tool sub-second? - file system yes certainly depends on the file system (could this be vfat?) perl no shell testno /usr/bin/test yes lsyes make yes touch -r yes here our coreutils 7.4 differ Ugh. If Cygwin weren't so slow, it would fall prey to this issue, too. I think we either need to reintroduce the 'sleep 1' in the build sanity check, or some other way to ensure that a file newly created by configure has a time stamp with a strictly larger integer part than the time stamp of the configure script. Any ideas of what the most portable way to achieve this could be? In view of the fact demonstrated above that the sub-seconds could be honored, truncated, or rounded, the actual requirement might be somewhat more stringent, but of course 1sec difference should always suffice. We may be able to get by with something like spawning off a ( sleep 1 ) early in the configure script, and ensuring that it has completed before we get to config.status creation. I'm a bit afraid of introducing 'kill' into configure scripts, however. Any less dangerous ideas? How about '( sleep 1; CREATE_A_FILE ) ' and later waiting until that file exists? Regards Peter Breitenlohner p...@mppmu.mpg.de
Re: [PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef
On Tue, 24 Nov 2009, Peter Breitenlohner wrote: as I mentioned a few weeks ago, I get a few FAILs when runnig 'make check' on the current Automake-git. Looking into the three tests I concluded that it must be a timing problem. Running ten times just these three tests I got: aclocal9: 6 FAIL + 4 PASS acloca10: 10 FAIL nodef: 8 FAIL + 2 PASS after applying the attached patch I got 10 PASSes for each test. The patch introduces a delay between successive invocations of aclocal. Probably using 'aclocal -f' would have the same effect, but a delay -- undesirable as it might be -- seems to be closer to a typical use case. BTW: There may be additional test suffering from the same problem. Hi Ralf, the patch probably should use '$sleep' instead of 'sleep 1'. Regards Peter Breitenlohner p...@mppmu.mpg.de
Re: [PATCH] Automake support for ObjC++
On Tue, 15 Sep 2009, Ralf Wildenhues wrote:
The other thing I'd like to see either in this patch or in a followup
one is your play-1.1 test rewritten as an Automake testsuite addition,
so that we have one full build test (including distcheck). (I can do
that if you don't want to.)
Hi Ralf,
attached is a patch adding a new test (objcxx3) doing just that, but you
might want to change that name. If OBJCXX doesn't work, configure exits
with 77 such that the test is skipped. It is assumed that a working OBJCXX
implies that OBJC and CXX work as well.
(I think a similar note applies to the configure.ac part of play-1.0 and
the Autoconf testsuite. If you have any issues with this, or don't want
to do the work, ping me and I'll look into it.)
That would be considerably more difficult for me, because I don't understand
at all how the Autoconf testsuite works. If you want to do that, please go
ahead.
Regards
Peter Breitenlohner p...@mppmu.mpg.deFrom 5998a1ac168c99447013301ede8ebb1138a56ef0 Mon Sep 17 00:00:00 2001
From: Peter Breitenlohner p...@mppmu.mpg.de
Date: Wed, 25 Nov 2009 10:29:10 +0100
Subject: [PATCH 3/3] A complete demo package using ObjC++ and distcheck
* tests/objcxx3.test: New test.
* tests/Makefile.am: Adjust.
Signed-off-by: Peter Breitenlohner p...@mppmu.mpg.de
---
tests/Makefile.am |1 +
tests/objcxx3.test | 82
2 files changed, 83 insertions(+), 0 deletions(-)
create mode 100755 tests/objcxx3.test
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 49708c8..0a4691a 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -487,6 +487,7 @@ objc.test \
objc2.test \
objcxx.test \
objcxx2.test \
+objcxx3.test \
obsolete.test \
order.test \
outdir.test \
diff --git a/tests/objcxx3.test b/tests/objcxx3.test
new file mode 100755
index 000..4807e59
--- /dev/null
+++ b/tests/objcxx3.test
@@ -0,0 +1,82 @@
+#! /bin/sh
+# Copyright (C) 2009 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+# Demo package using Objective C++ and doing distcheck.
+
+. ./defs || Exit 1
+
+set -e
+
+cat configure.in 'END'
+AC_INIT([play], [1.1], [...@mppmu.mpg.de])
+AC_PREREQ([2.65])
+AC_CONFIG_SRCDIR([play.c])
+AM_INIT_AUTOMAKE([foreign])
+AC_PROG_CC
+AC_PROG_CXX
+AC_PROG_OBJC
+AC_LANG_PUSH([Objective C++])
+AC_CACHE_CHECK([Objective C++ preprocessor],
+ [my_cv_preproc],
+ [AC_PREPROC_IFELSE([AC_LANG_PROGRAM([[#import objc/Object.h]],
+ [[[Object class]]])],
+ [my_cv_preproc=PASS],
+ [my_cv_preproc=FAIL])])
+AC_CACHE_CHECK([Objective C++ compiler],
+ [my_cv_compile],
+ [AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include stdarg.h]],
+[[extern void foo(int
i,...);]])],
+ [my_cv_compile=PASS],
+ [my_cv_compile=FAIL])])
+AC_LANG_POP([Objective C++])
+if test x$my_cv_preproc:$my_cv_compile != xPASS:PASS; then
+ AC_MSG_ERROR([Objective C++ compilation failed], 77)
+fi
+AC_CONFIG_HEADERS([config.h])
+AC_CONFIG_FILES([Makefile])
+AC_OUTPUT
+END
+
+cat Makefile.am 'END'
+bin_PROGRAMS = play
+play_SOURCES = play.c playxx.cxx playobjc.m playobjcxx.mm
+TESTS = play
+END
+
+cat play.c 'END'
+#include config.h
+#include stdio.h
+int main()
+{
+ printf(Hello, world! ( PACKAGE_STRING )\n);
+ return 0;
+}
+END
+
+echo '//' playxx.cxx
+
+echo '/* */' playobjc.m
+
+echo '//' playobjcxx.mm
+
+$ACLOCAL
+$AUTOCONF
+$AUTOHEADER
+$AUTOMAKE --add-missing
+
+./configure
+$MAKE
+$MAKE distcheck
--
1.6.4
[PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef
Hi Ralf, as I mentioned a few weeks ago, I get a few FAILs when runnig 'make check' on the current Automake-git. Looking into the three tests I concluded that it must be a timing problem. Running ten times just these three tests I got: aclocal9: 6 FAIL + 4 PASS acloca10: 10 FAIL nodef: 8 FAIL + 2 PASS after applying the attached patch I got 10 PASSes for each test. The patch introduces a delay between successive invocations of aclocal. Probably using 'aclocal -f' would have the same effect, but a delay -- undesirable as it might be -- seems to be closer to a typical use case. BTW: There may be additional test suffering from the same problem. Regards Peter Breitenlohner p...@mppmu.mpg.deFrom 717445fbf97fedcaeacefd55c4b078bd2a8c56c7 Mon Sep 17 00:00:00 2001 From: Peter Breitenlohner p...@mppmu.mpg.de Date: Mon, 23 Nov 2009 21:46:16 +0100 Subject: [PATCH] Add a delay so these tests succeed Signed-off-by: Peter Breitenlohner p...@mppmu.mpg.de --- tests/acloca10.test |4 tests/aclocal9.test |2 ++ tests/nodef.test|2 ++ 3 files changed, 8 insertions(+), 0 deletions(-) diff --git a/tests/acloca10.test b/tests/acloca10.test index 7716f2a..7576beb 100755 --- a/tests/acloca10.test +++ b/tests/acloca10.test @@ -55,6 +55,8 @@ grep MACRO3 aclocal.m4 test ! -f m4_1/macro.m4 test ! -f m4_2/macro.m4 +sleep 1 + $ACLOCAL -I m4_2 -I m4_1 $AUTOCONF ./configure @@ -65,6 +67,8 @@ grep MACRO3 aclocal.m4 test ! -f m4_1/macro.m4 test ! -f m4_2/macro.m4 +sleep 1 + ACLOCAL_TESTSUITE_FLAGS='-I m4_1 -I m4_2' $ACLOCAL --install $AUTOCONF diff --git a/tests/aclocal9.test b/tests/aclocal9.test index 325f6ae..913ff9a 100755 --- a/tests/aclocal9.test +++ b/tests/aclocal9.test @@ -42,6 +42,8 @@ $AUTOCONF grep macro11 foo grep macro21 foo +sleep 1 + $ACLOCAL -I m4_2 -I m4_1 $AUTOCONF ./configure diff --git a/tests/nodef.test b/tests/nodef.test index 1a58bb7..faadfe8 100755 --- a/tests/nodef.test +++ b/tests/nodef.test @@ -45,6 +45,8 @@ grep 'DEFS.*-DVERSION=\\UnIqUe' output # Then, check that PACKAGE and VERSION are not output if requested. +sleep 1 + cat configure.in 'END' AC_INIT AM_INIT_AUTOMAKE([UnIqUe_PaCkAgE], [UnIqUe_VeRsIoN], [no]) -- 1.6.4
Re: [PATCH] Automake support for ObjC++
On Tue, 15 Sep 2009, Ralf Wildenhues wrote:
Would you be so nice as to respin and simplify the patch under the
assumption that AC_PROG_OBJCXX exists? I think it should be sufficient
to just require new enough Autoconf for this to work, that way we can
avoid all the duplication and so on. This patch is targets 1.12 rather
than 1.11.1 anyway. Maybe it can even omit the objcxx.m4 file
completely?
Hi Ralf,
now that autoconf-2.65 is released, here the hopefully final version of
the patch for ObjC++ support in Autmake.
Regards
Peter Breitenlohner p...@mppmu.mpg.deFrom 71ce4de9db36dc8974a6982ce6d1f2245e8ccdf7 Mon Sep 17 00:00:00 2001
From: Peter Breitenlohner p...@mppmu.mpg.de
Date: Tue, 24 Nov 2009 12:03:29 +0100
Subject: [PATCH 2/2] Support for Objective C++
* NEWS: Announce and require Autoconf 2.65 or better.
* configure.ac: Require Autoconf 2.65 or better.
* automake.in: Register new language.
(lang_objcxx_rewrite): New subroutine.
(resolve_linker): Add OBJCXXLINK.
(%_am_macro_for_cond): Add am__fastdepOBJCXX and AC_PROG_OBJCXX.
(%-ac_macro_for_var): Add OBJCXX and OBJCXXFLAGS.
* m4/depend.m4 (_AM_DEPENDENCIES): Add OBJCXX.
* m4/init.m4 (AM_INIT_AUTOMAKE): Add AC_PROG_OBJCXX hook.
* tests/ext.test, tests/nodep2.test: Add Objective C++.
* tests/objcxx.test, tests.objcxx2.test: New tests.
* tests/Makefile.am: Adjust.
* doc/automake.texi (Objective C++ Support): New node.
(How the Linker is Chosen, Support for Other Languages): Adjust.
Signed-off-by: Peter Breitenlohner p...@mppmu.mpg.de
---
NEWS |9 ++
automake.in | 29 -
configure.ac |2 +
doc/automake.texi| 62 +
lib/Automake/Variable.pm |2 +
m4/depend.m4 |5 ++-
m4/init.m4 |6 +++-
tests/Makefile.am|2 +
tests/ext.test |7 +++--
tests/nodep2.test|6 +++-
tests/objcxx.test| 34 +
tests/objcxx2.test | 33
12 files changed, 181 insertions(+), 16 deletions(-)
create mode 100755 tests/objcxx.test
create mode 100755 tests/objcxx2.test
diff --git a/NEWS b/NEWS
index 0851e63..7e71e83 100644
--- a/NEWS
+++ b/NEWS
@@ -1,9 +1,18 @@
New in 1.11a:
+* Version requirements:
+
+ - Autoconf 2.65 or greater is required.
+
* Changes to automake:
- automake now generates silenced rules for texinfo outputs.
+* Languages changes:
+
+ - New support for Objective C++:
+- A new section of the manual documents the support.
+
* New targets:
- New `cscope' target to build a cscope database for the source tree.
diff --git a/automake.in b/automake.in
index 2af2897..99f42c5 100755
--- a/automake.in
+++ b/automake.in
@@ -783,6 +783,24 @@ register_language ('name' = 'objc',
'pure' = 1,
'extensions' = ['.m']);
+# Objective C++.
+register_language ('name' = 'objcxx',
+ 'Name' = 'Objective C++',
+ 'config_vars' = ['OBJCXX'],
+ 'linker' = 'OBJCXXLINK',
+ 'link' = '$(OBJCXXLD) $(AM_OBJCXXFLAGS) $(OBJCXXFLAGS)
$(AM_LDFLAGS) $(LDFLAGS) -o $@',
+ 'autodep' = 'OBJCXX',
+ 'flags' = ['OBJCXXFLAGS', 'CPPFLAGS'],
+ 'compile' = '$(OBJCXX) $(DEFS) $(DEFAULT_INCLUDES)
$(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_OBJCXXFLAGS) $(OBJCXXFLAGS)',
+ 'ccer' = 'OBJCXX',
+ 'compiler' = 'OBJCXXCOMPILE',
+ 'compile_flag' = '-c',
+ 'output_flag' = '-o',
+ 'lder' = 'OBJCXXLD',
+ 'ld' = '$(OBJCXX)',
+ 'pure' = 1,
+ 'extensions' = ['.mm']);
+
# Unified Parallel C.
register_language ('name' = 'upc',
'Name' = 'Unified Parallel C',
@@ -5897,6 +5915,12 @@ sub lang_objc_rewrite
return lang_sub_obj;
}
+# Rewrite a single Objective C++ file.
+sub lang_objcxx_rewrite
+{
+return lang_sub_obj;
+}
+
# Rewrite a single Unified Parallel C file.
sub lang_upc_rewrite
{
@@ -6174,7 +6198,7 @@ sub resolve_linker
{
my (%linkers) = @_;
-foreach my $l (qw(GCJLINK CXXLINK F77LINK FCLINK OBJCLINK UPCLINK))
+foreach my $l (qw(GCJLINK OBJCXXLINK CXXLINK F77LINK FCLINK OBJCLINK
UPCLINK))
{
return $l if defined $linkers{$l};
}
@@ -6364,13 +6388,14 @@ sub make_conditional_string ($$)
my %_am_macro_for_cond =
(
AMDEP = one of the compiler tests\n
- . AC_PROG_CC, AC_PROG_CXX, AC_PROG_CXX, AC_PROG_OBJC,\n
+ . AC_PROG_CC, AC_PROG_CXX, AC_PROG_OBJC, AC_PROG_OBJCXX,\n
. AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC,
am__fastdepCC = 'AC_PROG_CC',
am__fastdepCCAS = 'AM_PROG_AS',
am__fastdepCXX = 'AC_PROG_CXX',
am__fastdepGCJ = 'AM_PROG_GCJ',
am__fastdepOBJC = 'AC_PROG_OBJC',
+ am__fastdepOBJCXX = 'AC_PROG_OBJCXX
Re: [PATCH] Automake support for ObjC++
On Tue, 15 Sep 2009, Ralf Wildenhues wrote:
Would you be so nice as to respin and simplify the patch under the
assumption that AC_PROG_OBJCXX exists? I think it should be sufficient
to just require new enough Autoconf for this to work, that way we can
avoid all the duplication and so on. This patch is targets 1.12 rather
than 1.11.1 anyway. Maybe it can even omit the objcxx.m4 file
completely?
Hi Ralf,
attached is a new version of the patch. As I said earlier, I think we need
the m4/objcxx.m4 file in order to define AC_PROG_OBJCXX Co. The
definitions are exactly as in Autoconf-git, thus once Autoconf-2.65 is
released and can be required as prerequisite that file can be dropped.
At the same time the documentation for AC_PROG_OBJCXX in the manual should
go away and the reference to AC_PROG_OBJCXX changed accordingly -- unless
you prefer to do that right now.
I hope that Autoconf-2.65 will come before Automake-1.12 is ready.
I have just tested the patch with both Autoconf-2.64 (objcxx.m4 is required)
and Autoconf-2.64.56-dfc96 (git as of today, objcxx.m4 is not required).
The obcjxx tests pass but there are some mysterious failures (plus some
others that are caused locally and are understood):
for 2.64: aclocal9, acloca10, acloca14, nodef, python11
for 2.64.56-dfc96: aclocal9, acloca10, acloca18, missing4, nodef, python11
The tests were done on a pretty fast machine, my suspicion is that a sleep
might be required in some of these tests.
The other thing I'd like to see either in this patch or in a followup
one is your play-1.1 test rewritten as an Automake testsuite addition,
so that we have one full build test (including distcheck). (I can do
that if you don't want to.)
Here I am somewhat unsure what exactly needs to be done for a testsuite
case. If that is easy to explain I'll do it, otherwise I should better
leave it to you (and please feel free to add/modify copyright notices as
apropriate).
In any case, that maybe should be based on a newer version play-1.2 that
also includes a libtool library.
Regards
Peter Breitenlohner p...@mppmu.mpg.deFrom ec77c2ee94537892f6123754455ecf38aec80523 Mon Sep 17 00:00:00 2001
From: Peter Breitenlohner p...@mppmu.mpg.de
Date: Fri, 2 Oct 2009 23:41:40 +0200
Subject: [PATCH] Support for Objective C++
* m4/objcxx.m4: New Autoconf macros for Objective C++ language.
* m4/Makefile.am: Adjust.
* configure.ac: Require Autoconf 2.64 or better.
* automake.in: Register new language.
(lang_objcxx_rewrite): New subroutine.
(resolve_linker): Add OBJCXXLINK.
(%_am_macro_for_cond): Add am__fastdepOBJCXX and AC_PROG_OBJCXX.
* (%-ac_macro_for_var): Add OBJCXX and OBJCXXFLAGS.
* m4/depend.m4 (_AM_DEPENDENCIES): Add OBJCXX.
* m4/init.m4 (AM_INIT_AUTOMAKE): Add AC_PROG_OBJCXX hook.
* tests/ext.test, tests/nodep2.test: Adjust.
* tests/objcxx.test, tests.objcxx2.test: New tests.
* tests/Makefile.am: Adjust.
* doc/automake.texi (Objective C++ Support): New node.
(Public Macros): Document AC_PROG_OBJCXX, OBJCXX, and OBJCXXFLAGS.
(How the Linker is Chosen, Support for Other Languages): Adjust.
* NEWS: Announce and require Autoconf 2.64 or better.
Signed-off-by: Peter Breitenlohner p...@mppmu.mpg.de
---
NEWS | 10 +++
automake.in | 29 +++-
configure.ac |2 +
doc/automake.texi| 63 +++-
lib/Automake/Variable.pm |2 +
m4/Makefile.am |1 +
m4/depend.m4 |5 +-
m4/init.m4 |6 +-
m4/objcxx.m4 | 183 ++
tests/Makefile.am|2 +
tests/ext.test |7 +-
tests/nodep2.test|6 +-
tests/objcxx.test| 34 +
tests/objcxx2.test | 33
14 files changed, 370 insertions(+), 13 deletions(-)
create mode 100644 m4/objcxx.m4
create mode 100755 tests/objcxx.test
create mode 100755 tests/objcxx2.test
diff --git a/NEWS b/NEWS
index 26a8b31..fb98c4f 100644
--- a/NEWS
+++ b/NEWS
@@ -1,9 +1,19 @@
New in 1.11a:
+* Version requirements:
+
+ - Autoconf 2.64 or greater is required.
+
* Changes to automake:
- automake now generates silenced rules for texinfo outputs.
+* Languages changes:
+
+ - New support for Objective C++:
+- AC_PROG_OBJCXX looks for a ObjC++ compiler.
+- A new section of the manual documents the support.
+
Bugs fixed in 1.11a:
* Bugs introduced by 1.11:
diff --git a/automake.in b/automake.in
index 25ba40d..b7d9e75 100755
--- a/automake.in
+++ b/automake.in
@@ -783,6 +783,24 @@ register_language ('name' = 'objc',
'pure' = 1,
'extensions' = ['.m']);
+# Objective C++.
+register_language ('name' = 'objcxx',
+ 'Name' = 'Objective C++',
+ 'config_vars' = ['OBJCXX'],
+ 'linker' = 'OBJCXXLINK',
+ 'link' = '$(OBJCXXLD) $(AM_OBJCXXFLAGS) $(OBJCXXFLAGS)
$(AM_LDFLAGS) $(LDFLAGS) -o
Re: [PATCH] Automake support for ObjC++
On Tue, 15 Sep 2009, Ralf Wildenhues wrote: This new version requires autoconf-2.64 (otherwise aclocal fails) and defines AM_PROG_OBJCXX. A hook for AC_PROG_OBJCXX, eventually to be defined by Autoconf, is already in place. Would you be so nice as to respin and simplify the patch under the assumption that AC_PROG_OBJCXX exists? I think it should be sufficient to just require new enough Autoconf for this to work, that way we can avoid all the duplication and so on. This patch is targets 1.12 rather than 1.11.1 anyway. Maybe it can even omit the objcxx.m4 file completely? OK, I will leave out all the AM_PROG_OBJCXX stuff and pretend that AC_PROG_OBJCXX exists. However, as long as Autoconf doesn't provide it, we'll need the objcxx.m4 file to provide AC_PROG_OBJCXX; otherwise how could one do any tests. The other thing I'd like to see either in this patch or in a followup one is your play-1.1 test rewritten as an Automake testsuite addition, so that we have one full build test (including distcheck). (I can do that if you don't want to.) (I think a similar note applies to the configure.ac part of play-1.0 and the Autoconf testsuite. If you have any issues with this, or don't want to do the work, ping me and I'll look into it.) What precisely did you have in mind? I suppose just a somewhat cleaned up version of my old tarball(s), such that you can use them in an Automake testsuite addition. I'll do that it may take a little time (few weeks). = Two completely unrelated items: (1) I noticed that 'make uninstallcheck' does test for leftover installed files but not for symlinks (same for distcleancheck). I stumbled onto this because I had some symlinks installed via install-exec-hook but (due to a typo) not uninstalled via uninstall-hook; to my surprise this was never reported by distcheck. I suppose this is a bug and the fix is extremely trivial. Shall I send a separate report with patch or can you simply modify the definition of both distuninstallcheck_listfiles and distcleancheck_listfiles into 'find . -type f -o -type l -print' plus appropriate corrections to the manual? (2) The manual says that INCLUDES does the same job as AM_CPPFLAGS (or any per-target _CPPFLAGS' variable if it is used), and is an older name for the same functionality, and that INCLUDES is deprecated. The first part is more or less true. However, I wish that INCLUDES were not deprecated because it is sometimes convenient to use both, as e.g., INCLUDES = -Isome_dir # common flags AM_CPPFLAGS = -UPROG# additional flags (default) prog1_CPPFLAGS = -Dprog1# additional flags for prog1 prog2_CPPFLAGS = -Dprog2# additional flags for prog2 Of course, one could rewrite this as includes = -Isome_dir AM_CPPFLAGS = $(includes) -UPROG prog1_CPPFLAGS = $(includes) -Dprog1 prog2_CPPFLAGS = $(includes) -Dprog2 but why drop some (at least marginally) useful functionality. = Regards Peter Breitenlohner p...@mppmu.mpg.de
Re: [PATCH] Automake support for ObjC++
On Tue, 28 Jul 2009, Peter Breitenlohner wrote: now that autoconf-2.64 is released, here a revised version of the patch I sent you last week. This new version requires autoconf-2.64 (otherwise aclocal fails) and defines AM_PROG_OBJCXX. A hook for AC_PROG_OBJCXX, eventually to be defined by Autoconf, is already in place. Hi Ralf, I have done some more testing of this patch, with and without the corresponding patch for Automake-2.64 as well as with and without Libtool. Doing this I came across this question: Should the ObjC++ language set --tag=CXX for libtool, i.e. should the ObjC++ language definition specify 'libtool_tag' = 'CXX' or should it not? And somewhat related: should ObjC specify 'libtool_tag' = 'CC'? Regards Peter
[SPAM] Re: [PATCH] Automake support for ObjC++
On Thu, 23 Jul 2009, Peter Breitenlohner wrote:
On Wed, 22 Jul 2009, Ralf Wildenhues wrote:
Feel free to send it, if you have it anyway. More information can only
help. ...
here it is. ..
Hi Ralf,
now that autoconf-2.64 is released, here a revised version of the patch I
sent you last week.
This new version requires autoconf-2.64 (otherwise aclocal fails) and
defines AM_PROG_OBJCXX. A hook for AC_PROG_OBJCXX, eventually to be defined
by Autoconf, is already in place.
Regards
PeterFrom 8b198f23a2fc30cd4405a3594cc73a3e0ae3e3ba Mon Sep 17 00:00:00 2001
From: Peter Breitenlohner p...@mppmu.mpg.de
Date: Tue, 28 Jul 2009 15:12:42 +0200
Subject: [PATCH] Support for Objective C++
* m4/objcxx.m4: New Autoconf macros for Objective C++ language.
* m4/Makefile.am: Adjust.
* configure.ac: Require Autoconf 2.64 or better.
* automake.in: Register new language.
(lang_objcxx_rewrite): New subroutine.
(resolve_linker): Add OBJCXXLINK.
(%_am_macro_for_cond): Add am__fastdepOBJCXX and AM_PROG_OBJCXX.
* (%-ac_macro_for_var): Add OBJCXX and OBJCXXFLAGS.
* m4/depend.m4 (_AM_DEPENDENCIES): Add OBJCXX.
* m4/init.m4 (AM_INIT_AUTOMAKE): Add AC_PROG_OBJCXX hook.
* tests/ext.test, tests/nodep2.test: Adjust.
* tests/objcxx.test, tests.objcxx2.test: New tests.
* tests/Makefile.am: Adjust.
* doc/automake.texi (Objective C++ Support): New node.
(Public Macros): Documnet AM_PROG_OBCJXX, OBJCXX, and OBJCXXFLAGS.
(How the Linker is Chosen, Support for Other Languages): Adjust.
* NEWS: Announce and require Autoconf 2.64 or better.
Signed-off-by: Peter Breitenlohner p...@mppmu.mpg.de
---
NEWS | 10 +++
automake.in | 29 +++-
configure.ac |2 +
doc/automake.texi| 63 +++-
lib/Automake/Variable.pm |2 +
m4/Makefile.am |1 +
m4/depend.m4 |5 +-
m4/init.m4 |6 +-
m4/objcxx.m4 | 182 ++
tests/Makefile.am|2 +
tests/ext.test |7 +-
tests/nodep2.test|6 +-
tests/objcxx.test| 34 +
tests/objcxx2.test | 33
14 files changed, 369 insertions(+), 13 deletions(-)
create mode 100644 m4/objcxx.m4
create mode 100755 tests/objcxx.test
create mode 100755 tests/objcxx2.test
diff --git a/NEWS b/NEWS
index 7e14ed8..0ec2d6d 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,15 @@
New in 1.11a:
+* Version requirements:
+
+ - Autoconf 2.64 or greater is required.
+
+* Languages changes:
+
+ - New support for Objective C++:
+- AM_PROG_OBJCXX looks for a ObjC++ compiler.
+- A new section of the manual documents the support.
+
Bugs fixed in 1.11a:
* Bugs introduced by 1.11:
diff --git a/automake.in b/automake.in
index bab8c42..c6d172c 100755
--- a/automake.in
+++ b/automake.in
@@ -783,6 +783,24 @@ register_language ('name' = 'objc',
'pure' = 1,
'extensions' = ['.m']);
+# Objective C++.
+register_language ('name' = 'objcxx',
+ 'Name' = 'Objective C++',
+ 'config_vars' = ['OBJCXX'],
+ 'linker' = 'OBJCXXLINK',
+ 'link' = '$(OBJCXXLD) $(AM_OBJCXXFLAGS) $(OBJCXXFLAGS)
$(AM_LDFLAGS) $(LDFLAGS) -o $@',
+ 'autodep' = 'OBJCXX',
+ 'flags' = ['OBJCXXFLAGS', 'CPPFLAGS'],
+ 'compile' = '$(OBJCXX) $(DEFS) $(DEFAULT_INCLUDES)
$(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_OBJCXXFLAGS) $(OBJCXXFLAGS)',
+ 'ccer' = 'OBJCXX',
+ 'compiler' = 'OBJCXXCOMPILE',
+ 'compile_flag' = '-c',
+ 'output_flag' = '-o',
+ 'lder' = 'OBJCXXLD',
+ 'ld' = '$(OBJCXX)',
+ 'pure' = 1,
+ 'extensions' = ['.mm']);
+
# Unified Parallel C.
register_language ('name' = 'upc',
'Name' = 'Unified Parallel C',
@@ -5860,6 +5878,12 @@ sub lang_objc_rewrite
return lang_sub_obj;
}
+# Rewrite a single Objective C++ file.
+sub lang_objcxx_rewrite
+{
+return lang_sub_obj;
+}
+
# Rewrite a single Unified Parallel C file.
sub lang_upc_rewrite
{
@@ -6137,7 +6161,7 @@ sub resolve_linker
{
my (%linkers) = @_;
-foreach my $l (qw(GCJLINK CXXLINK F77LINK FCLINK OBJCLINK UPCLINK))
+foreach my $l (qw(GCJLINK OBJCXXLINK CXXLINK F77LINK FCLINK OBJCLINK
UPCLINK))
{
return $l if defined $linkers{$l};
}
@@ -6327,13 +6351,14 @@ sub make_conditional_string ($$)
my %_am_macro_for_cond =
(
AMDEP = one of the compiler tests\n
- . AC_PROG_CC, AC_PROG_CXX, AC_PROG_CXX, AC_PROG_OBJC,\n
+ . AC_PROG_CC, AC_PROG_CXX, AC_PROG_OBJC, AM_PROG_OBJCXX,\n
. AM_PROG_AS, AM_PROG_GCJ, AM_PROG_UPC,
am__fastdepCC = 'AC_PROG_CC',
am__fastdepCCAS = 'AM_PROG_AS',
am__fastdepCXX = 'AC_PROG_CXX',
am__fastdepGCJ = 'AM_PROG_GCJ',
am__fastdepOBJC = 'AC_PROG_OBJC
Re: Automake support for ObjC++
On Tue, 21 Jul 2009, Ralf Wildenhues wrote: AFAIK nobody else is working on patches yet; they would be very welcome. I suppose adding ObjC++ support should be very straightforward. Thanks. Hi Ralf, in the meantime I have created a patch for Automake support of ObjC++. It was indeed very straightforward. In a small toy example this works to my satifaction (of course only together with Autoconf from git plus the patch from earlier today). I forgot to mention: of course, this would require that Autoconf supports ObjC++. Are you aware of any plans into that direction? Nope. Since 2.64 might not be far away, you might want to do this first. (Otherwise, there is also the possibility for an AM_PROG_OBJCXX.) If the Autoconf patch makes it into 2.64, that then will be a requirement for ObjC++ support in Automake. Otherwise it is still possible to slightly rewrite the present Automake patch such that is uses AM_PROG_OBJCXX. However, that still requires autoconf-2.64 because otherwise aclocal can't trace the macro named 'AC_LANG(Objective C++)' which is part of A[CM]_PROG_OBJCXX. Shall I send the patch right now so you can inspect it, or shall I wait until autoconf-2.64 is released? Regards Peter
Automake support for ObjC++
Hi, are there any plans that Automake supports ObjC++ (as implemented in gcc-4.x)? In TeXlive there is one program that requires one ObjC++ (.mm) file when compiled for Mac OS X. With present Automake (1.11) that requires an ugly hack: (1) create a C++ wrapper including the .mm file (2) define a separate static library containing just one object file with this wrapper as source. (3) adding '-ObjC++' to the CXXFLAGS for that library All that would be much simpler, more transparent and less fragile with ObjC++ support from Automake. The implementation of such support seems to be fairly staightforward. In case there are no such plans, I could prepare some patches for this. Please let me know. Regards Peter Breitenlohner p...@mppmu.mpg.de
Re: Automake support for ObjC++
On Mon, 20 Jul 2009, Peter Breitenlohner wrote: are there any plans that Automake supports ObjC++ (as implemented in gcc-4.x)? I forgot to mention: of course, this would require that Autoconf supports ObjC++. Are you aware of any plans into that direction? Regards Peter
Re: How to tell Automake about dependencies between source files.
On Tue, 17 Mar 2009, Ralf Wildenhues wrote: Hello Bob and Ralf, thanks for your replies, unfortunately they gave me no new insight Well, do you distribute any files that depend on these built files? If you stick to distributing all files which are prerequisites to distributed files, then there should be no problem. That is, of course, true but not applicable in our case. These prerequisites are built by a tool (for the build system) that is part of the package, and it would be extremely inconvenient to distribute them. But showing an example failure is always the easiest to analyze. Let me be somewhat more explicit and give you an (idealized) Makefile.am (fragment): if COND bin_PROGRAMS = prog endif COND prog_SOURCES = foo.c foo.h nodist_prog_SOURCES = bar.h bar.h: tool bar.orig .tool $(srcdir)/bar.orig === This fails (if COND is true) because, in our case, foo.c includes bar.h, but that is only known to Make once foo.c has been compiled (as least with depmode=gcc3). What we really would need is a dependency foo.o: bar.h but then this ought to be foo.$(OBJEXT) or maybe prog-foo.$(OBJEXT) and, more important, would prevent Automake from generating a rule for this compilation. = I have tried adding BUILT_SOURCES = bar.h but then tool will run even if COND is false $(prog_SOURCES): bar.h is somewhat better until I run 'make dist'. I could use if COND BUILT_SOURCES = bar.h endif COND or if COND $(prog_SOURCES): bar.h endif COND and these two almost do what I need, unless: COND is false but prog nevertheless needs to be built because it appears as dependency of something else, or I might have second thoughts and say make prog This will then fail. === Moreover, telling Automake that foo.c depends on bar.h is a lie (foo.c will always be older than bar.h) and may have other undesirable consequences. What I really would need is a way to tell Automake: 'before you can compile foo.c you must first create bar.h', and I have found no way to do that (other than writing a compilation rule as Automake would do). === The above example may look somewhat artificial. However, it is a stripped down version of what we really need. Regards Peter Breitenlohner p...@mppmu.mpg.de
How to tell Automake about dependencies between source files.
Hi, I have to following problem (in an modernized TeX Live build system): A program is built conditionally from distributed and generated sources. Some of the distributed C files include generated headers and therefore can not be compiled before these headers are generated. A related problem: a tool generates a C file plus header from one source, and another C file plus header from another source. Each of these C files includes both headers, therefore the C files can not be compiled before both headers have been created. What is the best way to teach this kind of dependencies to Automake, avoiding unnecessary tasks, not interfering with Automake's automatic dependency tracking, and not having 'make dist' gratuitously build files that are never used. Best regards Peter Breitenlohner p...@mppmu.mpg.de
Re: automake/535: Extract correct man section from files in MAN_MANS
On Sat, 7 Mar 2009, Ralf Wildenhues wrote: Erm, I've already done all that in the patch that I posted; and I have applied to master. So there is nothing left to do on this topic, except to argue (if you want) that this should be fixed in branch-1-10. :-) Hello Ralf, not really, since there is a reasonable workaround. BTW: any idea about the schedule for for 1-11? == There is, however, a completely different problem. I am using Automake together with an m4/ directory, and my top-level Makefile.am starts with 'ACLOCAL_AMFLAGS = -I m4'. Consequently the generated aclocal.m4 ends with several 'm4_include([m4/xxx.m4])'s. The problem is, that when any of these m4/*.m4 files is changed (and maintainermode is enabled explicitly or by default), then 'make' runs aclocal but doesn't update aclocal.m4 because that remains the same. Thus aclocal is run again and again, quite inconvenient. IMHO a better alternative would be to touch aclocal.m4 and consequently run configure and automake once, but never again until some other files are changed. I found the present behaviour fairly annoying and would prefer if it could be changed as indicated above. However, I am not quite sure how that would be done best: in aclocal or in the rule generated by autmoake? Regards, Peter Breitenlohner p...@mppmu.mpg.de
Re: automake/535: Extract correct man section from files in MAN_MANS
On Sat, 7 Mar 2009, Ralf Wildenhues wrote: Attached is a small patch (current git) correcting this problem. @@ -39,8 +39,8 @@ if %?NOTRANS_MANS% ## Extract all items from notrans_man_MANS that should go in this section. ## This must be done dynamically to support conditionals. ?HAVE_NOTRANS? l2='%NOTRANS_LIST%'; for i in $$l2; do \ -## Accept files like `foo.1c'. -?HAVE_NOTRANS? case $$i in *.%SECTION%*) echo $$i;; esac; \ +## Accept for `man1' files like `foo.1c' but not `sub.1/foo.2' or `foo-2.1.4'. +?HAVE_NOTRANS? case `echo $$i | sed -e 's,.*\.,,'` in %SECTION%*) echo $$i;; esac; \ ?HAVE_NOTRANS? done; \ ## Extract basename of manpage, change the extension if needed. } | while read p; do \ This has the disadvantage that we're now again forking at least twice per installed file. The point of the install rule changes in master was to make them faster! :-) I don't know a good way to fix this without adding any forks at all, but the patch below fixes the issue for master with adding two forks per set of man pages installed. It uses the same regex for matching the section as is used in automake.in. Hallo Ralf, actually, I never thought about that aspect. I think there is a way to reduce the number of forks, replacing the two loops by one such that one could extract ext rather early and reuse it later on. However, this would be major surgery and require extensive testing. The idea is roughly this, e.g., for the install-man1 target: dot_seen=no for i in $(man1_MANS) . $(man_MANS); do if test x$i = x.; then dot_seen=yes continue fi ext=`echo $i | sed -e 's/^.*\\.//'` case $ext in 1*) ;; *) if test $dot_seen = yes; then continue else ext=1 fi ;; esac [proceed as now, reusing the ext extracted above] done Could also be 'dot_seen=false', 'dot_seen=:', and 'if $dot_seen; then'. This is for branch-1-10. Perhaps something analogous can be done for the new scheme in git master (just updated my local copy, still have to study it). Comments? +# Let's play with $DESTDIR too, it shouldn't hurt. +./configure --prefix='' --mandir=/man Let's just omit --prefix here, rather than passing an empty one. Also, let's add a 'make uninstall' as well as the notrans man pages, so all changed code paths are exercised; and rename a bit, so we can better test that no wrong directories are created. Shall I try to do that, or will you (knowing better exactly what you have in mind)? Regards, Peter Breitenlohner p...@mppmu.mpg.de
automake-gnats: #533 and #535
Hi Ralf, recently I have reported two automake problems #533 and #535 (#534 duplicates #533, my mistake) with patch and test case. They have been assigned to Alexandre Duret-Lutz a...@gnu.org, but according to the git log his last activity was in June 2006. Maybe you can have a look. 533: applies equally to git master and branch 1.10, but may need some refinement. 535: applies to git master, but an analogous change ought to be applied to branch 1.10. I promised a second patch for that but couldn't convince automake-gnats to accept another attachment. Thus I attach it here. Regards Peter Breitenlohner p...@mppmu.mpg.dediff -ur -N -x 'automake.info*' -x version.texi -x stamp-vti automake-1.10.2.orig/ChangeLog automake-1.10.2/ChangeLog --- automake-1.10.2.orig/ChangeLog 2008-11-23 09:36:41.0 +0100 +++ automake-1.10.2/ChangeLog 2009-02-02 15:27:42.0 +0100 @@ -1,3 +1,9 @@ +2009-02-02 Peter Breitenlohner p...@mppmu.mpg.de + + Extract correct man section from files in MAN_MANS. + * lib/am/mans.am: Extract correct man section. + * tests/Makefile.am, tests/man5.test: New test case. + 2008-11-23 Ralf Wildenhues ralf.wildenh...@gmx.de * configure.ac, NEWS: Bump version to 1.10.2. diff -ur -N -x 'automake.info*' -x version.texi -x stamp-vti automake-1.10.2.orig/lib/am/mans.am automake-1.10.2/lib/am/mans.am --- automake-1.10.2.orig/lib/am/mans.am 2008-11-23 09:29:00.0 +0100 +++ automake-1.10.2/lib/am/mans.am 2009-02-02 15:36:06.0 +0100 @@ -37,9 +37,9 @@ ## This must be done dynamically to support conditionals. l2='$(man_MANS) $(dist_man_MANS) $(nodist_man_MANS)'; \ for i in $$l2; do \ - case $$i in \ -## Have to accept files like `foo.1c'. - *.%SECTION%*) list=$$list $$i ;; \ +## Have to accept (for man1) files like `foo.1c' but not `sub.1/foo.2' or `foo-2.1.4'. + case `echo $$i | sed -e 's,.*\.,,'` in \ + %SECTION%*) list=$$list $$i ;; \ esac; \ done; \ for i in $$list; do \ @@ -77,9 +77,9 @@ ## This must be done dynamically to support conditionals. l2='$(man_MANS) $(dist_man_MANS) $(nodist_man_MANS)'; \ for i in $$l2; do \ - case $$i in \ -## Have to accept files like `foo.1c'. - *.%SECTION%*) list=$$list $$i ;; \ +## Have to accept (for man1) files like `foo.1c' but not `sub.1/foo.2' or `foo-2.1.4'. + case `echo $$i | sed -e 's,.*\.,,'` in \ + %SECTION%*) list=$$list $$i ;; \ esac; \ done; \ for i in $$list; do \ diff -ur -N -x 'automake.info*' -x version.texi -x stamp-vti automake-1.10.2.orig/tests/Makefile.am automake-1.10.2/tests/Makefile.am --- automake-1.10.2.orig/tests/Makefile.am 2008-11-23 09:29:00.0 +0100 +++ automake-1.10.2/tests/Makefile.am 2009-02-02 15:28:59.0 +0100 @@ -369,6 +369,7 @@ man.test \ man2.test \ man3.test \ +man5.test \ mclean.test \ mdate.test \ mdate2.test \ diff -ur -N -x 'automake.info*' -x version.texi -x stamp-vti automake-1.10.2.orig/tests/Makefile.in automake-1.10.2/tests/Makefile.in --- automake-1.10.2.orig/tests/Makefile.in 2008-11-23 09:37:12.0 +0100 +++ automake-1.10.2/tests/Makefile.in 2009-02-02 15:29:00.0 +0100 @@ -502,6 +502,7 @@ man.test \ man2.test \ man3.test \ +man5.test \ mclean.test \ mdate.test \ mdate2.test \ diff -ur -N -x 'automake.info*' -x version.texi -x stamp-vti automake-1.10.2.orig/tests/man5.test automake-1.10.2/tests/man5.test --- automake-1.10.2.orig/tests/man5.test1970-01-01 01:00:00.0 +0100 +++ automake-1.10.2/tests/man5.test 2009-02-02 15:30:26.0 +0100 @@ -0,0 +1,47 @@ +#! /bin/sh +# Copyright (C) 2009 Free Software Foundation, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 3, or (at your option) +# any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see http://www.gnu.org/licenses/. + +# Make sure to extract the correct mansection from files in man_MANS. + +. ./defs || Exit 1 + +set -e + +echo AC_OUTPUT configure.in + +cat Makefile.am 'END' +man_MANS = foo-1.4.5/foo.2 foo-1.4.5/bar.4 baz-1.4.2 +END + +mkdir foo-1.4.5 + +: foo-1.4.5/foo.2 +: foo-1.4.5/bar.4 +: baz-1.4.2 + +$ACLOCAL +$AUTOCONF +$AUTOMAKE + +# Let's play with $DESTDIR too, it shouldn't hurt. +./configure --prefix='' --mandir=/man +DESTDIR=`pwd`/_inst $MAKE -e install + +test -f ./_inst/man/man2/foo.2 +test -f ./_inst/man/man2/baz-1.4.2 +test -f ./_inst/man/man4/bar.4 +test ! -f
Re: Implementing notrans_man_MANS
On Tue, 11 Mar 2008, Ralf Wildenhues wrote: Having one test is fine, and it looks good, too. I suppose we might want to change the MANS line and the install-manX rules to be flattened, they already look pretty ugly in the Makefile. But that can happen in a followup patch. Hello Ralf, I guess that could mean a rule starting with install-man6: dist_man_MANS man_MANS nodist_man_MANS notrans_dist_man_MANS notrans_man_MANS \ notrans_nodist_man_MANS notrans_nodist_man_MANS If so, that would make grep '^install-man6:' Makefile.in | grep '\$(notrans_nodist_man_MANS)' in the present notrans.test FAIL. Maybe it would then be better that the notrans.test script creates none of the files and have them all created by make rules. (At one time I was not sure if Automake complains if some of these files are missing.) To really test these dependencies one could even do: rm -f foo.1 z-baz.man $MAKE install-man1 rm -f bar.2 z-bar.man $MAKE install-man2 and so on. Regards, Peter
Re: Implementing notrans_man_MANS
On Thu, 6 Mar 2008, Ralf Wildenhues wrote:
* Peter Breitenlohner wrote on Thu, Mar 06, 2008 at 01:27:05PM CET:
or still something else. If so please indicate what.
Oh sorry, I was in a hurry and not thinking. What I meant was that
while you can't wrap arbitrary lines ending in backslash-newline in `if
%?NOTRANS_MANS%/else/endif', you can do so at a finer grainage than
whole rules: it's just that it won't work after lines ending in
backslash.
To some extent this is independent of the question you ask about the
rule target names: whether you interleave trans and notrans in the .am
file and whether you give trans and notrans different target names need
not be dealt with at the same time. So please for now leave you patch
as is, but only change all those NOTR/DOTR prefixes to use if/else/endif
(which includes a few lines of duplication in the .am file).
Clearer now? If not, then I guess I can also patch that later.
Hi Ralf,
yes, thanks. However, I can only use if/endif if/endif and not if/else/endif
because a section may have trans_ as well as notrans_ man pages.
=
Attached are revised versions of the three patches. I hope they take care of
all your earlier comments.
patch-03-notrans_MANS-impl:
The new variables names are more or less self explanatory (I hope).
I had to use
@unsorted_deps = (keys %notrans_vars, keys %trans_vars,
keys %notrans_this_sect, keys %trans_this_sect);
my @deps = sort @unsorted_deps;
instead of
my @deps = sort (keys %notrans_vars, keys %trans_vars,
keys %notrans_this_sect, keys %trans_this_sect);
because this may give a perl warning [sort (...) used as function],
resulting in three test (instsh.tes, location.test, warnopts.test) to FAIL.
patch-04-notrans_MANS-doc:
I have slightly reworded the text preceding the example, and hope this
clarifies the intent.
patch-05-notrans_MANS-test:
notrans.test now contains all combinations. I have incorporated the checks
that used to be in man4.test into notrans.test, because otherwise there
would have been much repetition. Hope this is OK. If so, remember not to
mention man4.test in the ChangLog. If not, I could make that two separate
tests.
The install-man depedndencies are checked either directly (inspecting
Makefile.in) or indirectly (letting make generate the files).
=
regards
Peter Breitenlohner [EMAIL PROTECTED]diff -ur -N -x 'automake.info*' -x version.texi -x stamp-vti
automake-1.10.1.orig/automake.in automake-1.10.1/automake.in
--- automake-1.10.1.orig/automake.in2008-02-19 18:07:41.0 +0100
+++ automake-1.10.1/automake.in 2008-03-08 00:10:34.0 +0100
@@ -3363,27 +3363,39 @@
# Find all the sections in use. We do this by first looking for
# standard sections, and then looking for any additional
# sections used in man_MANS.
- my (%sections, %vlist);
+ my (%sections, %notrans_sections, %trans_sections,
+ %notrans_vars, %trans_vars, %notrans_sect_vars, %trans_sect_vars);
# We handle nodist_ for uniformity. man pages aren't distributed
# by default so it isn't actually very important.
+ foreach my $npfx ('', 'notrans_')
+{
foreach my $pfx ('', 'dist_', 'nodist_')
{
# Add more sections as needed.
foreach my $section ('0'..'9', 'n', 'l')
{
- my $varname = $pfx . 'man' . $section . '_MANS';
+ my $varname = $npfx . $pfx . 'man' . $section . '_MANS';
if (var ($varname))
{
$sections{$section} = 1;
$varname = '$(' . $varname . ')';
- $vlist{$varname} = 1;
+ if ($npfx eq 'notrans_')
+ {
+ $notrans_sections{$section} = 1;
+ $notrans_sect_vars{$varname} = 1;
+ }
+ else
+ {
+ $trans_sections{$section} = 1;
+ $trans_sect_vars{$varname} = 1;
+ }
push_dist_common ($varname)
if $pfx eq 'dist_';
}
}
- my $varname = $pfx . 'man_MANS';
+ my $varname = $npfx . $pfx . 'man_MANS';
my $var = var ($varname);
if ($var)
{
@@ -3393,28 +3405,87 @@
if (/\.([0-9a-z])([a-z]*)$/)
{
$sections{$1} = 1;
+ if ($npfx eq 'notrans_')
+ {
+ $notrans_sections{$1} = 1;
+ }
+ else
+ {
+ $trans_sections{$1} = 1;
+ }
}
}
$varname = '$(' . $varname . ')';
- $vlist{$varname} = 1;
+ if ($npfx eq 'notrans_
Re: Implementing notrans_man_MANS
On Wed, 5 Mar 2008, Ralf Wildenhues wrote:
Well, here's a review of your patches. If you have time to address the
comments, that would be great, otherwise I will eventually do it.
Hi Ralf,
I will go through your comments and think most of them pose no problem. For
the moment just a few remarks/questions:
This triple loop is already at 72 iterations. Not good for performance.
If this grows further, we may have to access variables in a different
manner here.
I assume you are worried by the total number of 72 iterations, not by the
fact that they come from three nested loops. Given the Automake
infrastructure (to the extent I understand it) I see no alternative.
+?NOTRY?l2='%NOTRZ%'; \
+?NOTRY?for i in $$l2; do \
...
+?NOTR? $(INSTALL_DATA) $$file $(DESTDIR)$(man%SECTION%dir)/$$inst; \
+?NOTR? done
Note to self: should rewrite the above when applying the multi-file
install.
What is multi-file install? Maybe I don't need to know.
Also, the whole thing would probably be a lot more readable if the
?NOTR?/?DOTR? prefixes vanished and were replaced by full rules, wrapped
in `if %?NOTRANS_MANS%'. That would be a better name for NOTR, and
since it would then only appear a couple of times, it could be longer
without pain, too.
I have tried to wrap the make rule fragments by something like
`if %?XXX%' but failed, maybe I got the syntax wrong. However, from
some comments elsewhere I concluded that at present this is not possible.
Do you mean something like:
install-man: install-man1 install-notrans-man1
install-man1: trans_DEPENDENCIES
trans_RULES
install-notrans-man1: notrans_DEPENDENCIES
notrans_RULES
That should not be too difficult. Shall I try it?
[EMAIL PROTECTED] must be specified first when used in conjunction with
+either @samp{dist_} or @samp{nodist_} (@pxref{Dist}). For instance:
Can this limitation be lifted (without making the code much slower)?
I wouldn't know how, and there is an analogous limitation elsewhere:
nobase_dist_pkgdata_DATA
+./configure --program-prefix=gnu- --prefix `pwd`/inst --mandir `pwd`/inst/man
Please quote instances of `pwd' for the master testsuite.
Like --prefix `pwd`/inst for Windows paths containing spaces? I just
copied this from transform.test. A quick grep shows there are still plenty
of unquoted pwd's around.
BTW: Which one is better: `--prefix PREFIX' or `--prefix=PREFIX'?
==
In the meantime I have some ideas how to handle manpage translations. Mainly
an Autoconf/Automake macro and Makefile.am stuff, plus a little bit of help
from Automake. To whom should I send this, when finished to write it up?
Regards Peter
Re: Implementing notrans_man_MANS
On Tue, 19 Feb 2008, Ralf Wildenhues wrote:
How should I proceed, once all that is finished? Email to you and/or
automake bugzilla?
automake-patches@gnu.org is best.
Are unified diffs against the autoamke-1.10.1 tarball OK?
Yes.
What about re-indenting existing code?
Please as a separate patch if possible, and please following the
already-used style.
Hallo Ralf,
attached are five patches (the diffs are actually against the result of
applying your patch for PR 516 from 2008-01-22):
1. patch-02-notrans_MANS-reindent:
Reindentation of a section in automake.in, anticipating an additional
foreach loop (it was less work to do this first).
2. patch-03-notrans_MANS-impl:
The actual implementation of `notrans_'. The patch looks awful but the
logic in the resulting patched file should be reasonably clear.
At the same time the dependencies for `install-man%SECTION%' have been
revised. All make variables not used in Makefile.am are omitted from the
install/uninstall rules. All those used in the rules also appear as
dependencies.
One consequence: make dist_man_MANS='bar.1 baz.5' install-man will only
work well if `dist_man_MANS' is used in Makefile.am and Automake has
generated the relevant (!notrans_) part of the install-man1 and
install-man5 rules. So ... ?
3. patch-04-notrans_MANS-doc:
Texinfo documentation for the notrans_ prefix.
4. patch-05-notrans_MANS-test:
Two new test cases for missing dependencies and the notrans_ prefix.
5. automake-1.10.1-ChangeLog:
Proposed ChangeLog entry.
==
Please feel free to revise the wording in texinfo, comments, and/or
ChangeLog.
regards
Peter Breitenlohner [EMAIL PROTECTED]Prepare for implementation of notrans_man_MANS: anticipate
an additional foreach loop and reindent accordingly.
Note: `diff -b' yields nothing.
diff -ur -N automake-1.10.1.orig/automake.in automake-1.10.1/automake.in
--- automake-1.10.1.orig/automake.in2008-01-21 23:11:41.0 +0100
+++ automake-1.10.1/automake.in 2008-02-19 18:07:41.0 +0100
@@ -3366,42 +3366,42 @@
my (%sections, %vlist);
# We handle nodist_ for uniformity. man pages aren't distributed
# by default so it isn't actually very important.
- foreach my $pfx ('', 'dist_', 'nodist_')
-{
- # Add more sections as needed.
- foreach my $section ('0'..'9', 'n', 'l')
+ foreach my $pfx ('', 'dist_', 'nodist_')
{
- my $varname = $pfx . 'man' . $section . '_MANS';
- if (var ($varname))
+ # Add more sections as needed.
+ foreach my $section ('0'..'9', 'n', 'l')
{
- $sections{$section} = 1;
- $varname = '$(' . $varname . ')';
- $vlist{$varname} = 1;
+ my $varname = $pfx . 'man' . $section . '_MANS';
+ if (var ($varname))
+ {
+ $sections{$section} = 1;
+ $varname = '$(' . $varname . ')';
+ $vlist{$varname} = 1;
- push_dist_common ($varname)
- if $pfx eq 'dist_';
+ push_dist_common ($varname)
+ if $pfx eq 'dist_';
+ }
}
- }
- my $varname = $pfx . 'man_MANS';
- my $var = var ($varname);
- if ($var)
- {
- foreach ($var-value_as_list_recursive)
+ my $varname = $pfx . 'man_MANS';
+ my $var = var ($varname);
+ if ($var)
{
- # A page like `foo.1c' goes into man1dir.
- if (/\.([0-9a-z])([a-z]*)$/)
+ foreach ($var-value_as_list_recursive)
{
- $sections{$1} = 1;
+ # A page like `foo.1c' goes into man1dir.
+ if (/\.([0-9a-z])([a-z]*)$/)
+ {
+ $sections{$1} = 1;
+ }
}
- }
- $varname = '$(' . $varname . ')';
- $vlist{$varname} = 1;
- push_dist_common ($varname)
- if $pfx eq 'dist_';
+ $varname = '$(' . $varname . ')';
+ $vlist{$varname} = 1;
+ push_dist_common ($varname)
+ if $pfx eq 'dist_';
+ }
}
-}
return unless %sections;
diff -ur -N -x 'automake.info*' -x version.texi -x stamp-vti
automake-1.10.1.orig/automake.in automake-1.10.1/automake.in
--- automake-1.10.1.orig/automake.in2008-02-19 18:07:41.0 +0100
+++ automake-1.10.1/automake.in 2008-02-20 01:52:26.0 +0100
@@ -3363,27 +3363,38 @@
# Find all the sections in use. We do this by first looking for
# standard sections, and then looking for any additional
# sections used in man_MANS.
- my (%sections, %vlist);
+ my (%sections, %nsections, %tsections, %nvlist, %tvlist, %nsvlist, %tsvlist);
# We handle nodist_ for uniformity. man pages aren't distributed
# by default so it isn't actually very important.
+ foreach my $npfx ('', 'notrans_
Implementing notrans_man_MANS (Was: Automake bug #516 -- and more)
On Wed, 30 Jan 2008, Ralf Wildenhues wrote: Hello Ralf, * Peter Breitenlohner wrote on Wed, Jan 23, 2008 at 10:28:28AM CET: [...] (1) In some cases it is completely inadequate to apply the program name transform to manpage names. [...] Maybe that could be taken care of by something like notransform_MAN_MANS (needs a better name). notrans_man_MANS sounds good to me. I now have a working version of notrans_man1_MANS Co, but I noticed an additional problem: The target 'install-man1' tries to install, e.g., '$(dist_man1_MANS)' but doesn't depend on it. I want to fix that as well, at the same time omitting unused variables. Still missing are: (1) documentation in autoconf.texi, (2) a test case, and (3) a ChangeLog entry. How should I proceed, once all that is finished? Email to you and/or automake bugzilla? Are unified diffs against the autoamke-1.10.1 tarball OK? What about re-indenting existing code? (2) There are packages with translated manpages -- good. But automake provides no way to supress their installation or to install them for a subset of the available languages -- not good. I'll come back to this at some later time. Regards Peter
Re: Automake bug #516 -- and more
On Tue, 22 Jan 2008, Ralf Wildenhues wrote: Hello Ralf, I did take a look at history now, and think that your patch is ok, and the order reversing just an oversight. The patch is missing a ChangeLog entry and a test. Providing them would have saved me time processing the bug. Thanks a lot. I am terribly disappointed that I never got any reaction and that this bug is still present in the new release. And you've made that quite clear by spamming it to five lists instead of to bug-automake as noted. I've limited that to automake lists now. Sorry, that was caused by simply replying to the original mail. My frustration was mostly due to the fact that I never got any reaction. I think I could have provided a ChangeLog entry and a test, if asked for it. --- I recently stumbled (once again) at two other manpage related automake problems, where I'd like to try for solutions provided there is a realistic chance that such solutions would be included in a future automake release. The problems are these: (1) In some cases it is completely inadequate to apply the program name transform to manpage names. E.g., in the man-db package there is manpath.1 describing the manpath command (should be transformed), and manpath.5 describing the format of the manpath configuration file (should certainly not be transformed). Maybe that could be taken care of by something like notransform_MAN_MANS (needs a better name). Moreover, renaming manpath=xmanpath and manpath.1=xmanpath.1 without changing the manpage contents is sort of strange. (2) There are packages with translated manpages -- good. But automake provides no way to supress their installation or to install them for a subset of the available languages -- not good. At the moment all available translated manpages are installed unconditionally (under the assumption that the packaging system of a distribution takes care of this?). I think something analogous to --disable-nls and/or LINGUAS=xxx for translated manpages is very desirable. --- What is your opinion? Regards, Peter Breitenlohner [EMAIL PROTECTED]
Re: GNU Automake 1.10.1 released -- bug #516 is still there
On Tue, 22 Jan 2008, Ralf Wildenhues wrote: I'm pleased to announce the release of Automake 1.10.1. Automake is a tool Very good, BUT more than a year ago I filed a bug report (automake#516), after sending an email some month earlier: automake generated Makefiles install manpages from the source tree in preference to those from the build tree together with a tiny and IMHO uncontroversial patch solving this problem. I am terribly disappointed that I never got any reaction and that this bug is still present in the new release. regards Peter Breitenlohner [EMAIL PROTECTED]
Re: MAINTAINERCLEANFILES in srcdir
On Thu, 15 Mar 2007, Stepan Kasal wrote: Hello Ralf, On Thu, Mar 15, 2007 at 09:11:37AM +0100, Ralf Wildenhues wrote: * Stepan Kasal wrote on Wed, Mar 14, 2007 at 01:34:06PM CET: -test -n $(MAINTAINERCLEANFILES) \ rm -f $(MAINTAINERCLEANFILES) \ cd $(srcdir) rm -f $(MAINTAINERCLEANFILES) . Hello Ralf, Stepan, quite some time ago I sent an email about a different but somewhat related problem (together with a very small and simple patch): When some manpages are present in both the source and build tree, the automake generated rules install those from the source tree and not those from the build tree as it should be. Unfortunately I never got an answer and last time I looked in CVS this bug was still there. Couldn't you take care of that problem? regards Peter Breitenlohner [EMAIL PROTECTED]
A problem (bug) in automake (1.10 and earlier version)
I have noticed the following problem (bug) in automake-1.10:
(1) A package (ImageMagick-6.3.0) uses configure to generate manpages with
substitutions (e.g., .1 from .1.in) but also distributes the
generated manpages from an older version (i.e., with wrong substitutions).
(2) The automake-generated rule to install manpages looks for the files to
install FIRST under ${srcdir} and THEN under the current directory.
===
The effect of (1)+(2) is, that the manpages with the wrong substitutions are
installed.
===
(1) is certainly not the right way to do things.
On the other hand I would think that (2) is equally wrong. Whenever a file
is to be installed, then the automake-generated rules should FIRST look for
that file in the current directory and THEN under ${srcdir}!
===
Peter Breitenlohner [EMAIL PROTECTED]
Re: GNU Automake 1.9.3 released
On Mon, 1 Nov 2004, Alexandre Duret-Lutz wrote: We're pleased to announce the release of Automake 1.9.3. This is a bug-fix release, the list of bugs fixed is appended. Hi, I just fetched and built automake-1.9.3. During make check I got the same three unexpected FAIL's as for 1.9.2. Tho output is attached. BTW: The installed version of automake is 1.8.4 regards Peter Breitenlohner [EMAIL PROTECTED]make -Ctests VERBOSE=1 TESTS='makej.test missing.test missing2.test' check make: Entering directory `/.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests' make defs aclocal-1.9 automake-1.9 make[1]: Entering directory `/.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests' make[1]: `defs' is up to date. make[1]: `aclocal-1.9' is up to date. make[1]: `automake-1.9' is up to date. make[1]: Leaving directory `/.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests' make check-TESTS make[1]: Entering directory `/.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests' /.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests:/bin:/home/pcl321/peb/bin/Linux:/home/pcl321/peb/bin:/usr/local/bin:/usr/local/X11/bin:/usr/local/tex/bin:/usr/local/java/bin:/opt/rsi/bin:/opt/UPS/bin:/opt/UPS/sbin:/opt/Wolfram/bin:/opt/PGI/bin:/opt/OpenOffice/bin:/usr/X11R6/bin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/athena/bin:/usr/local/condor/bin:/usr/local/condor/sbin:. makej: running make --version -v | grep GNU GNU Make 3.80 === Running test ../../automake-1.9.3/tests/makej.test /.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests/testSubDir version7 configure 2.718 checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes configure: creating ./config.status config.status: creating Makefile config.status: creating config.h make all-am make[1]: Entering directory `/.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests/testSubDir' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests/testSubDir' cd . /bin/sh /.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests/testSubDir/missing --run aclocal-1.9 cd . /bin/sh /.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests/testSubDir/missing --run autoconf cd . /bin/sh /.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests/testSubDir/missing --run automake-1.9 --foreign /bin/sh ./config.status --recheck sh: autom4te.cache/output.1t: No such file or directory autom4te: /usr/bin/m4 failed with exit status: 1 configure.in: no proper invocation of AM_INIT_AUTOMAKE was found. configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE, configure.in: that aclocal.m4 is present in the top-level directory, configure.in: and that aclocal.m4 was recently regenerated (using aclocal). automake: no `Makefile.am' found for any configure output automake: Did you forget AC_CONFIG_FILES([Makefile]) in configure.in? running /bin/sh ./configure --no-create --no-recursion checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... make: *** [Makefile.in] Error 1 make: *** Waiting for unfinished jobs yes checking for gawk... gawk checking whether make sets $(MAKE)... yes configure: creating ./config.status FAIL: makej.test /.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests:/bin:/home/pcl321/peb/bin/Linux:/home/pcl321/peb/bin:/usr/local/bin:/usr/local/X11/bin:/usr/local/tex/bin:/usr/local/java/bin:/opt/rsi/bin:/opt/UPS/bin:/opt/UPS/sbin:/opt/Wolfram/bin:/opt/PGI/bin:/opt/OpenOffice/bin:/usr/X11R6/bin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/athena/bin:/usr/local/condor/bin:/usr/local/condor/sbin:. === Running test ../../automake-1.9.3/tests/missing.test /.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests/testSubDir checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes configure: creating ./config.status config.status: creating Makefile make: Nothing to be done for `all'. cd . /bin/sh /.th/thsrc/archive/gnu/automake/automake-1.9.3-build-linux-gnulibc2/tests/testSubDir/missing --run automake-1.9 --foreign aclocal.m4:668: error: Autoconf version or higher is required aclocal.m4:668: the top level autom4te: /usr/bin/m4 failed with exit status: 63 configure.in: no proper invocation of AM_INIT_AUTOMAKE was found. configure.in: You should verify that configure.in invokes AM_INIT_AUTOMAKE, configure.in: that aclocal.m4 is present in the top-level directory, configure.in: and that aclocal.m4 was recently regenerated (using aclocal). automake: no `Makefile.am' found for any configure output
