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
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',
parallel compression in 'make dist' (was: [PATCH] Automake support for ObjC++)
* Peter Breitenlohner wrote on Wed, Sep 16, 2009 at 10:11:58AM CEST:
Another completely unrelated item:
it would be nice if Automake could run gzip and bzip2 (and others) in
parallel when creating the distribution tarballs. In a parallel make that
could save quite some time when running dist(check) for a largish project.
Feasible?
I think so. Can you try this patch and check whether it improves `make
dist' time for you significantly? Thanks.
I did some quick best of three tests on the GraphicsMagick (uses gzip,
bzip2, and lzma) and the Automake packages on a 2-way GNU/Linux system:
GM Automake
before, -j1: 34.283.56
before, -j : 34.033.57
after, -j1: 34.543.65
after, -j : 27.113.13
indicating that the extra make recursion seems to be acceptable, and the
optimization worthwhile for some packages. Notably, -j2 isn't helpful
for GM, as it starts the slowest encoder late only.
Further notes:
With the patch below, the compressor pipes can run in parallel.
I do not see how we can avoid the multiple 'tar' invocations without
an intermediate on-disk file. Leaving it as it is currently, since I
don't know a good way to measure which way the balance tilts on average.
We need to ensure that the individual compression rules don't remove the
distdir after they are done. We could just set
am__remove_distdir=:
but that would also cause a small semantic change: currently, the
distdir rule may engage in some sanity checks, then cleans up the
distdir (from eventual old remains), then populates it. I'd like
the sanity checks to remain happening before the removal of old stuff:
that way, the checks happen early, and if one of them fails, we haven't
otherwise touched the distdir tree at all yet.
Nice side-effect: it lowers Makefile.in size in common cases. :-)
BTW, this is definitely a 1.12-only change: while I'm fairly certain
that it won't cause big backward compatibility issues in practice, the
introduction of another make recursion might expose some variable
override-related oddities.
Thanks,
Ralf
dist: allow running several compressors in parallel.
* lib/am/distdir.am (am__post_remove_distdir): New internal
variable.
(DIST_TARGETS): New variable, set to list of chosen distribution
formats.
(dist-gzip, dist-bzip2, dist-lzma, dist-xz, dist-tarZ)
(dist-shar, dist-zip): Use $(am__post_remove_distdir).
(dist, dist-all): Do not depend on distdir. Instead of
replicating each compression command, use a recursive invocation
to allow running all $(DIST_TARGETS) in parallel.
* NEWS: Update.
Report by Peter Breitenlohner.
diff --git a/NEWS b/NEWS
index 01aa492..97f4aca 100644
--- a/NEWS
+++ b/NEWS
@@ -26,6 +26,8 @@ New in 1.11a:
- Automake is licensed under GPLv3+ now. As before, the generated aclocal.m4
and Makefile.in files carry all-permissive licenses.
+ - The `dist' and `dist-all' targets now can run compressors in parallel.
+
Bugs fixed in 1.11a:
* Bugs introduced by 1.11:
diff --git a/lib/am/distdir.am b/lib/am/distdir.am
index 9664587..e698ec3 100644
--- a/lib/am/distdir.am
+++ b/lib/am/distdir.am
@@ -26,7 +26,7 @@ am__remove_distdir = \
{ test ! -d $(distdir) \
|| { find $(distdir) -type d ! -perm -200 -exec chmod u+w {} ';' \
rm -fr $(distdir); }; }
-
+am__post_remove_distdir = $(am__remove_distdir)
endif %?TOPDIR_P%
if %?SUBDIRS%
@@ -335,48 +335,55 @@ endif %?TOPDIR_P%
if %?TOPDIR_P%
?GZIP?DIST_ARCHIVES += $(distdir).tar.gz
+?GZIP?DIST_TARGETS += dist-gzip
GZIP_ENV = --best
.PHONY: dist-gzip
dist-gzip: distdir
tardir=$(distdir) $(am__tar) | GZIP=$(GZIP_ENV) gzip -c
$(distdir).tar.gz
- $(am__remove_distdir)
+ $(am__post_remove_distdir)
?BZIP2?DIST_ARCHIVES += $(distdir).tar.bz2
+?BZIP2?DIST_TARGETS += dist-bzip2
.PHONY: dist-bzip2
dist-bzip2: distdir
tardir=$(distdir) $(am__tar) | bzip2 -9 -c $(distdir).tar.bz2
- $(am__remove_distdir)
+ $(am__post_remove_distdir)
?LZMA?DIST_ARCHIVES += $(distdir).tar.lzma
+?LZMA?DIST_TARGETS += dist-lzma
.PHONY: dist-lzma
dist-lzma: distdir
tardir=$(distdir) $(am__tar) | lzma -9 -c $(distdir).tar.lzma
- $(am__remove_distdir)
+ $(am__post_remove_distdir)
?XZ?DIST_ARCHIVES += $(distdir).tar.xz
+?XZ?DIST_TARGETS += dist-xz
.PHONY: dist-xz
dist-xz: distdir
tardir=$(distdir) $(am__tar) | xz -c $(distdir).tar.xz
- $(am__remove_distdir)
+ $(am__post_remove_distdir)
?COMPRESS?DIST_ARCHIVES += $(distdir).tar.Z
+?COMPRESS?DIST_TARGETS += dist-tarZ
.PHONY: dist-tarZ
dist-tarZ: distdir
tardir=$(distdir) $(am__tar) | compress -c $(distdir).tar.Z
- $(am__remove_distdir)
+ $(am__post_remove_distdir)
?SHAR?DIST_ARCHIVES += $(distdir).shar.gz
+?SHAR?DIST_TARGETS += dist-shar
.PHONY: dist-shar
dist-shar: distdir
shar $(distdir) | GZIP=$(GZIP_ENV) gzip -c $(distdir).shar.gz
-
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 $@',
+
unrelated issues (was: [PATCH] Automake support for ObjC++)
Hello Peter, * Peter Breitenlohner wrote on Wed, Sep 16, 2009 at 10:11:58AM CEST: Another completely unrelated item: It would be nice if you could start a new email in a new thread for an unrelated issue. I keep mails/threads which contain todo items, and sometimes look for them by subject or author name. Mails which deal with more than one subject are good candidates for getting lost. If the topic is related, or a thread is evolving to a new topic, then it may be good to keep the thread but adjust the subject. Thanks, Ralf
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++
Hello Peter, * Peter Breitenlohner wrote on Wed, Aug 05, 2009 at 10:23:37AM CEST: 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. I have done some more testing of this patch, with and without the corresponding patch for Automake-2.64 and I still haven't looked at the patch at all. :-/ 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'? Both don't really sound right. The Right Thing[tm] would be for Libtool to introduce new tags for both languages. At least if there is a chance that the compilers from the C and C++ ones, respectively. For now, I guess it would be sufficient however to set libtool_tag to CC and CXX, respectively (can you please test that?). We definitely need to fix Libtool func_mode_compile to support the .mm .M and maybe also the .mi .mii extensions however. Automake should probably not use or discourage .M as that will cause problems on case-insensitive systems. Your patch doesn't seem to use it, good. Cheers, Ralf
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 =
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
Re: Automake support for ObjC++
* Peter Breitenlohner wrote on Wed, Jul 22, 2009 at 05:29:52PM CEST: Shall I send the patch right now so you can inspect it, or shall I wait until autoconf-2.64 is released? Feel free to send it, if you have it anyway. More information can only help. But a review might be awhile. Thanks, Ralf
Re: Automake support for ObjC++
Hello Peter, * Peter Breitenlohner wrote on Mon, Jul 20, 2009 at 03:35:48PM CEST: On Mon, 20 Jul 2009, Peter Breitenlohner wrote: are there any plans that Automake supports ObjC++ (as implemented in gcc-4.x)? AFAIK nobody else is working on patches yet; they would be very welcome. I suppose adding ObjC++ support should be very straightforward. Thanks. 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.) Cheers, Ralf
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
