Autoconf and Automake support for ObjC++

[Peter Breitenlohner]

On Tue, 21 Jul 2009, Ralf Wildenhues wrote:

> * 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.)

Hi Eric,

can you tell me the approximate schedule for Autoconf 2.64. I'd like to
create patches adding support for ObjC++, preferably in time for 2.64.

=====================

Another item:

During the last several months I was involved in a complete rewrite of
the TeXlive (formerly teTeX) build system using Automake and modernized
Autoconf.

In doing so I "had" to use the names of various cache variables, in order to
write, e.g.
  AC_CHECK_HEADERS([inttypes.h sys/types.h <more_headers>])
  if test "x$ac_cv_header_inttypes_h:$ac_cv_header_sys_types_h" \
  = xno:no; then
   ...
  fi
instead of the more clumsy and less efficient
  AC_CHECK_HEADERS([inttypes.h], [have_inttypes_h=yes],
        [have_inttypes_h=no])
  AC_CHECK_HEADERS([sys/types.h], [have_sys_types_h=yes],
  [have_sys_types_h=no])
  AC_CHECK_HEADERS([<more_headers>])
  if test "x$have_inttypes_h:$have_sys_types_h" = xno:no; then
   ...
  fi

One set of cache variables, where this is particularly important is
ac_cv_search_* if I want to use, e.g.,
  AC_SEARCH_LIBS([connect], [socket nsl])
but want to have the required library (if any) in a separate variable such
as SOCKET_LIBS and not added to LIBS.

It would be nice if these ac_cv_* names could be made part of the API, i.e.,
be frozen and documented.

=====================

Regards
Peter Breitenlohner <peb@...>


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Peter Breitenlohner on 7/21/2009 3:26 AM:
>>>> 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.

Seconded, especially since autoconf already has ObjC and C++ support, so
you have two similar languages to borrow from.

> can you tell me the approximate schedule for Autoconf 2.64. I'd like to
> create patches adding support for ObjC++, preferably in time for 2.64.

I'm under a lot of pressure to get 2.64 out this week before I go on a two
week vacation.  I'm sorry to say it, but that probably means ObjC++
support will have to wait for 2.65.  But don't let that deter you from
starting to write the patches now.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkplpgEACgkQ84KuGfSFAYALPQCgnZnHKGTWIa+dzO91tyir1+M+
assAoMtGgKvP39T4LSqLJxRrnaQt/4aj
=Rb5S
-----END PGP SIGNATURE-----


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Peter Breitenlohner]

On Tue, 21 Jul 2009, Eric Blake wrote:

> Seconded, especially since autoconf already has ObjC and C++ support, so
> you have two similar languages to borrow from.

Hi Eric,

attached is a patch implementing autoconf support for ObjC++.  As expected
this was extremely straightforward and only marginally intrusive.

The only somewhat problematic aspect is the list of potential ObjC++
compilers -- pure guesswork from my side.

There are no tests for ObjC, thus none for ObjC++ either.  I think
eventually some such tests should be added.

> I'm under a lot of pressure to get 2.64 out this week before I go on a two
> week vacation.  I'm sorry to say it, but that probably means ObjC++
> support will have to wait for 2.65.

Maybe the patch is still in time for 2.64.  That would be very helpful for
the Automake part of all that.  Attempting to implement automake support for
ObjC++ without a released autoconf version providing the basics would be
rather awkward.

Regards
Peter
From 8c1de4d15f1550956abace86ad6877e25dc05e9a Mon Sep 17 00:00:00 2001
From: Peter Breitenlohner <peb@...>
Date: Tue, 21 Jul 2009 22:55:34 +0200
Subject: [PATCH] Implement and document Objective C++ support.

* lib/autoconf/c.m4 (AC_LANG(Objective C++), AC_LANG_OBJCXX)
(AC_LANG_PREPROC(Objective C++), AC_PROG_OBJCXXCPP)
(AC_LANG_COMPILER(Objective C++), AC_PROG_OBJCXX)
(_AC_PROG_OBJCXX_G): New macros.
(_AC_ARG_VAR_CPPFLAGS, _AC_ARG_VAR_LDFLAGS)
(_AC_ARG_VAR_LIBS): Adjusted.
* doc/autoconf.texi (Objective C++ Compiler): New node.
(Preset Output Variables): Document OBJCXXFLAGS.
(Language Choice): Document `Objective C++' language.
* NEWS: Updated.

* tests/local.at (AT_CHECK_ENV): Ignore AC_SUBSTed Objective C++
related variables.

Signed-off-by: Peter Breitenlohner <peb@...>
---
 NEWS              |    3 +
 doc/autoconf.texi |   68 ++++++++++++++++++++--
 lib/autoconf/c.m4 |  167 +++++++++++++++++++++++++++++++++++++++++++++++++++--
 tests/local.at    |    1 +
 4 files changed, 229 insertions(+), 10 deletions(-)

diff --git a/NEWS b/NEWS
index ef67c77..3ad6b07 100644
--- a/NEWS
+++ b/NEWS
@@ -3,6 +3,9 @@ GNU Autoconf NEWS - User visible changes.
 * Major changes in Autoconf 2.64 (2009-??-??) [stable]
   Released by Eric Blake, based on git versions 2.63b.*.
 
+** New macros to support Objective C++.
+   AC_PROG_OBJCXX, AC_PROG_OBJCXXCPP.
+
 ** AS_IF and AS_CASE have been taught to avoid syntax errors even when
    given arguments that expand to just whitespace.
 
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 34df30b..f94811f 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -391,6 +391,7 @@ Compilers and Preprocessors
 * C Compiler::                  Checking its characteristics
 * C++ Compiler::                Likewise
 * Objective C Compiler::        Likewise
+* Objective C++ Compiler::      Likewise
 * Erlang Compiler and Interpreter::  Likewise
 * Fortran Compiler::            Likewise
 
@@ -2404,11 +2405,12 @@ needs to be processed by @command{configure} in order to be used.
 @defvar CPPFLAGS
 @evindex CPPFLAGS
 @ovindex CPPFLAGS
-Preprocessor options for the C, C++, and Objective C preprocessors and
-compilers.  If
+Preprocessor options for the C, C++, Objective C, and Objective C++
+preprocessors and compilers.  If
 it is not set in the environment when @command{configure} runs, the default
 value is empty.  @command{configure} uses this variable when preprocessing
-or compiling programs to test for C, C++, and Objective C features.
+or compiling programs to test for C, C++, Objective C, and Objective C++
+features.
 
 This variable's contents should contain options like @option{-I},
 @option{-D}, and @option{-U} that affect only the behavior of the
@@ -2499,7 +2501,7 @@ programs to test for Fortran 77 features.
 Options for the linker.  If it is not set
 in the environment when @command{configure} runs, the default value is empty.
 @command{configure} uses this variable when linking programs to test for
-C, C++, Objective C, and Fortran features.
+C, C++, Objective C, Objective C++, and Fortran features.
 
 This variable's contents should contain options like @option{-s} and
 @option{-L} that affect only the behavior of the linker.  Please see the
@@ -2517,7 +2519,8 @@ Don't use this variable to pass library names
 but some Autoconf macros may prepend extra libraries to this variable if
 those libraries are found and provide necessary functions, see
 @ref{Libraries}.  @command{configure} uses this variable when linking
-programs to test for C, C++, and Fortran features.
+programs to test for C, C++, Objective C, Objective C++, and Fortran
+features.
 @end defvar
 
 @defvar OBJCFLAGS
@@ -2527,6 +2530,13 @@ Debugging and optimization options for the Objective C compiler.  It
 acts like @code{CFLAGS}, but for Objective C instead of C.
 @end defvar
 
+@defvar OBJCXXFLAGS
+@evindex OBJCXXFLAGS
+@ovindex OBJCXXFLAGS
+Debugging and optimization options for the Objective C++ compiler.  It
+acts like @code{CXXFLAGS}, but for Objective C++ instead of C++.
+@end defvar
+
 @defvar builddir
 @ovindex builddir
 Rigorously equal to @samp{.}.  Added for symmetry only.
@@ -6521,6 +6531,7 @@ compiling.
 * C Compiler::                  Checking its characteristics
 * C++ Compiler::                Likewise
 * Objective C Compiler::        Likewise
+* Objective C++ Compiler::      Likewise
 * Erlang Compiler and Interpreter::  Likewise
 * Fortran Compiler::            Likewise
 @end menu
@@ -7224,6 +7235,47 @@ preprocessor.  If @samp{$OBJC -E} doesn't work, @file{/lib/cpp} is used.
 @end defmac
 
 
+@node Objective C++ Compiler
+@subsection Objective C++ Compiler Characteristics
+
+
+@defmac AC_PROG_OBJCXX (@ovar{compiler-search-list})
+@acindex{PROG_OBJCXX}
+@evindex OBJCXX
+@evindex OBJCXXFLAGS
+@ovindex OBJCXX
+@ovindex OBJCXXFLAGS
+Determine an Objective C++ compiler to use.  If @code{OBJCXX} is not already
+set in the environment, check for Objective C++ compilers.  Set output
+variable @code{OBJCXX} to the name of the compiler found.
+
+This macro may, however, be invoked with an optional first argument
+which, if specified, must be a blank-separated list of Objective C++ compilers
+to search for.  This just gives the user an opportunity to specify an
+alternative search list for the Objective C++ compiler.  For example, if you
+didn't like the default order, then you could invoke @code{AC_PROG_OBJCXX}
+like this:
+
+@example
+AC_PROG_OBJCXX([gcc g++ objcc++ objcxx])
+@end example
+
+If using the @acronym{GNU} Objective C++ compiler, set shell variable
+@code{GOBJCXX} to @samp{yes}.  If output variable @code{OBJCXXFLAGS} was not
+already set, set it to @option{-g -O2} for the @acronym{GNU} Objective C++
+compiler (@option{-O2} on systems where @command{gcc} does not accept
+@option{-g}), or @option{-g} for other compilers.
+@end defmac
+
+@defmac AC_PROG_OBJCXXCPP
+@acindex{PROG_OBJCXXCPP}
+@evindex OBJCXXCPP
+@ovindex OBJCXXCPP
+Set output variable @code{OBJCXXCPP} to a command that runs the Objective C++
+preprocessor.  If @samp{$OBJCXX -E} doesn't work, @file{/lib/cpp} is used.
+@end defmac
+
+
 @node Erlang Compiler and Interpreter
 @subsection Erlang Compiler and Interpreter Characteristics
 @cindex Erlang
@@ -8031,6 +8083,12 @@ Do compilation tests using @code{OBJC} and @code{OBJCPP} and use
 extension @file{.m} for test programs.  Use compilation flags:
 @code{CPPFLAGS} with @code{OBJCPP}, and both @code{CPPFLAGS} and
 @code{OBJCFLAGS} with @code{OBJC}.
+
+@item Objective C++
+Do compilation tests using @code{OBJCXX} and @code{OBJCXXCPP} and use
+extension @file{.mm} for test programs.  Use compilation flags:
+@code{CPPFLAGS} with @code{OBJCXXCPP}, and both @code{CPPFLAGS} and
+@code{OBJCXXFLAGS} with @code{OBJCXX}.
 @end table
 @end defmac
 
diff --git a/lib/autoconf/c.m4 b/lib/autoconf/c.m4
index 33d1895..98ab261 100644
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -58,10 +58,11 @@
 #      1a. C   2a. C
 #      1b. C++
 #      1c. Objective C
+#      1d. Objective C++
 #
 # 3. Looking for a compiler
 #    And possibly the associated preprocessor.
-#      3a. C   3b. C++   3c. Objective C
+#      3a. C   3b. C++   3c. Objective C   3d. Objective C++
 #
 # 4. Compilers' characteristics.
 #      4a. C
@@ -296,6 +297,23 @@ AU_DEFUN([AC_LANG_OBJC], [AC_LANG(Objective C)])
 
 
 
+## -------------------------------- ##
+## 1d. The Objective C++ language.  ##
+## -------------------------------- ##
+
+
+# AC_LANG(Objective C++)
+# ----------------------
+AC_LANG_DEFINE([Objective C++], [objcxx], [OBJCXX], [C++],
+[ac_ext=mm
+ac_cpp='$OBJCXXCPP $CPPFLAGS'
+ac_compile='$OBJCXX -c $OBJCXXFLAGS $CPPFLAGS conftest.$ac_ext >&AS_MESSAGE_LOG_FD'
+ac_link='$OBJCXX -o conftest$ac_exeext $OBJCXXFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&AS_MESSAGE_LOG_FD'
+ac_compiler_gnu=$ac_cv_objcxx_compiler_gnu
+])
+
+
+
 ## -------------------------------------------- ##
 ## 3. Looking for Compilers and Preprocessors.  ##
 ## -------------------------------------------- ##
@@ -308,17 +326,17 @@ AU_DEFUN([AC_LANG_OBJC], [AC_LANG(Objective C)])
 # _AC_ARG_VAR_CPPFLAGS
 # --------------------
 # Document and register CPPFLAGS, which is used by
-# AC_PROG_{CC, CPP, CXX, CXXCPP, OBJC, OBJCPP}.
+# AC_PROG_{CC, CPP, CXX, CXXCPP, OBJC, OBJCPP, OBJCXX, OBJCXXCPP}.
 AC_DEFUN([_AC_ARG_VAR_CPPFLAGS],
 [AC_ARG_VAR([CPPFLAGS],
-    [C/C++/Objective C preprocessor flags, e.g. -I<include dir>
+    [(Objective) C/C++ preprocessor flags, e.g. -I<include dir>
      if you have headers in a nonstandard directory <include dir>])])
 
 
 # _AC_ARG_VAR_LDFLAGS
 # -------------------
 # Document and register LDFLAGS, which is used by
-# AC_PROG_{CC, CXX, F77, FC, OBJC}.
+# AC_PROG_{CC, CXX, F77, FC, OBJC, OBJCXX}.
 AC_DEFUN([_AC_ARG_VAR_LDFLAGS],
 [AC_ARG_VAR([LDFLAGS],
     [linker flags, e.g. -L<lib dir> if you have libraries in a
@@ -328,7 +346,7 @@ AC_DEFUN([_AC_ARG_VAR_LDFLAGS],
 # _AC_ARG_VAR_LIBS
 # ----------------
 # Document and register LIBS, which is used by
-# AC_PROG_{CC, CXX, F77, FC, OBJS}.
+# AC_PROG_{CC, CXX, F77, FC, OBJC, OBJCXX}.
 AC_DEFUN([_AC_ARG_VAR_LIBS],
 [AC_ARG_VAR([LIBS],
     [libraries to pass to the linker, e.g. -l<library>])])
@@ -947,6 +965,145 @@ fi[]dnl
 
 
 
+# -------------------------------- #
+# 3d. The Objective C++ compiler.  #
+# -------------------------------- #
+
+
+# AC_LANG_PREPROC(Objective C++)
+# ------------------------------
+# Find the Objective C++ preprocessor.  Must be AC_DEFUN'd to be AC_REQUIRE'able.
+AC_DEFUN([AC_LANG_PREPROC(Objective C++)],
+[AC_REQUIRE([AC_PROG_OBJCXXCPP])])
+
+
+# AC_PROG_OBJCXXCPP
+# -----------------
+# Find a working Objective C++ preprocessor.
+AC_DEFUN([AC_PROG_OBJCXXCPP],
+[AC_REQUIRE([AC_PROG_OBJCXX])dnl
+AC_ARG_VAR([OBJCXXCPP],   [Objective C++ preprocessor])dnl
+_AC_ARG_VAR_CPPFLAGS()dnl
+AC_LANG_PUSH(Objective C++)dnl
+AC_MSG_CHECKING([how to run the Objective C++ preprocessor])
+if test -z "$OBJCXXCPP"; then
+  AC_CACHE_VAL(ac_cv_prog_OBJCXXCPP,
+  [dnl
+    # Double quotes because OBJCXXCPP needs to be expanded
+    for OBJCXXCPP in "$OBJCXX -E" "/lib/cpp"
+    do
+      _AC_PROG_PREPROC_WORKS_IFELSE([break])
+    done
+    ac_cv_prog_OBJCXXCPP=$OBJCXXCPP
+  ])dnl
+  OBJCXXCPP=$ac_cv_prog_OBJCXXCPP
+else
+  ac_cv_prog_OBJCXXCPP=$OBJCXXCPP
+fi
+AC_MSG_RESULT([$OBJCXXCPP])
+_AC_PROG_PREPROC_WORKS_IFELSE([],
+  [AC_MSG_FAILURE([Objective C++ preprocessor "$OBJCXXCPP" fails sanity check])])
+AC_SUBST(OBJCXXCPP)dnl
+AC_LANG_POP(Objective C++)dnl
+])# AC_PROG_OBJCXXCPP
+
+
+# AC_LANG_COMPILER(Objective C++)
+# -------------------------------
+# Find the Objective C++ compiler.  Must be AC_DEFUN'd to be AC_REQUIRE'able.
+AC_DEFUN([AC_LANG_COMPILER(Objective C++)],
+[AC_REQUIRE([AC_PROG_OBJCXX])])
+
+
+
+# AC_PROG_OBJCXX([LIST-OF-COMPILERS])
+# ---------------------------------
+# LIST-OF-COMPILERS is a space separated list of Objective C++ compilers to
+# search for (if not specified, a default list is used).  This just gives
+# the user an opportunity to specify an alternative search list for the
+# Objective C++ compiler.
+# FIXME: this list is pure guesswork
+# objc++ StepStone Objective-C++ compiler (also "standard" name for OBJCXX)
+# objcxx David Stes' POC.  If you installed this, you likely want it.
+# c++    Native C++ compiler (for instance, Apple).
+# CXX    You never know.
+AN_MAKEVAR([OBJCXX],  [AC_PROG_OBJCXX])
+AN_PROGRAM([objcxx],  [AC_PROG_OBJCXX])
+AC_DEFUN([AC_PROG_OBJCXX],
+[AC_LANG_PUSH(Objective C++)dnl
+AC_ARG_VAR([OBJCXX],      [Objective C++ compiler command])dnl
+AC_ARG_VAR([OBJCXXFLAGS], [Objective C++ compiler flags])dnl
+_AC_ARG_VAR_LDFLAGS()dnl
+_AC_ARG_VAR_LIBS()dnl
+_AC_ARG_VAR_CPPFLAGS()dnl
+_AC_ARG_VAR_PRECIOUS([OBJCXX])dnl
+AC_CHECK_TOOLS(OBJCXX,
+       [m4_default([$1], [g++ objc++ objcxx c++ CXX])],
+       g++)
+# Provide some information about the compiler.
+_AS_ECHO_LOG([checking for _AC_LANG compiler version])
+set X $ac_compile
+ac_compiler=$[2]
+for ac_option in --version -v -V -qversion; do
+  _AC_DO_LIMIT([$ac_compiler $ac_option >&AS_MESSAGE_LOG_FD])
+done
+
+m4_expand_once([_AC_COMPILER_EXEEXT])[]dnl
+m4_expand_once([_AC_COMPILER_OBJEXT])[]dnl
+_AC_LANG_COMPILER_GNU
+if test $ac_compiler_gnu = yes; then
+  GOBJCXX=yes
+else
+  GOBJCXX=
+fi
+_AC_PROG_OBJCXX_G
+AC_LANG_POP(Objective C++)dnl
+])# AC_PROG_OBJCXX
+
+
+# _AC_PROG_OBJCXX_G
+# -----------------
+# Check whether -g works, even if OBJCFLAGS is set, in case the package
+# plays around with OBJCFLAGS (such as to build both debugging and
+# normal versions of a library), tasteless as that idea is.
+# Don't consider -g to work if it generates warnings when plain compiles don't.
+m4_define([_AC_PROG_OBJCXX_G],
+[ac_test_OBJCXXFLAGS=${OBJCXXFLAGS+set}
+ac_save_OBJCXXFLAGS=$OBJCXXFLAGS
+AC_CACHE_CHECK(whether $OBJCXX accepts -g, ac_cv_prog_objcxx_g,
+  [ac_save_objcxx_werror_flag=$ac_objcxx_werror_flag
+   ac_objcxx_werror_flag=yes
+   ac_cv_prog_objcxx_g=no
+   OBJCXXFLAGS="-g"
+   _AC_COMPILE_IFELSE([AC_LANG_PROGRAM()],
+     [ac_cv_prog_objcxx_g=yes],
+     [OBJCXXFLAGS=""
+      _AC_COMPILE_IFELSE([AC_LANG_PROGRAM()],
+ [],
+ [ac_objcxx_werror_flag=$ac_save_objcxx_werror_flag
+ OBJCXXFLAGS="-g"
+ _AC_COMPILE_IFELSE([AC_LANG_PROGRAM()],
+   [ac_cv_prog_objcxx_g=yes])])])
+   ac_objcxx_werror_flag=$ac_save_objcx_werror_flag])
+if test "$ac_test_OBJCXXFLAGS" = set; then
+  OBJCXXFLAGS=$ac_save_OBJCXXFLAGS
+elif test $ac_cv_prog_objcxx_g = yes; then
+  if test "$GOBJCXX" = yes; then
+    OBJCXXFLAGS="-g -O2"
+  else
+    OBJCXXFLAGS="-g"
+  fi
+else
+  if test "$GOBJCXX" = yes; then
+    OBJCXXFLAGS="-O2"
+  else
+    OBJCXXFLAGS=
+  fi
+fi[]dnl
+])# _AC_PROG_OBJCXX_G
+
+
+
 ## ------------------------------- ##
 ## 4. Compilers' characteristics.  ##
 ## ------------------------------- ##
diff --git a/tests/local.at b/tests/local.at
index 8a81835..19a82c8 100644
--- a/tests/local.at
+++ b/tests/local.at
@@ -297,6 +297,7 @@ if test -f state-env.before && test -f state-env.after; then
       [CC|CFLAGS|CPP|GCC|CXX|CXXFLAGS|CXXCPP|GXX|F77|FFLAGS|FLIBS|G77],
       [ERL|ERLC|ERLCFLAGS|ERLANG_PATH_ERL|ERLANG_ROOT_DIR|ERLANG_LIB_DIR],
       [ERLANG_INSTALL_LIB_DIR|OBJC|OBJCPP|OBJCFLAGS],
+      [OBJCXX|OBJCXXCPP|OBJCXXFLAGS],
       [OPENMP_CFLAGS],
       [LIBS|LIB@&t@OBJS|LTLIBOBJS|LDFLAGS],
       [INSTALL(_(DATA|PROGRAM|SCRIPT))?],
--
1.6.3.3


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Peter Breitenlohner]

On Wed, 22 Jul 2009, Peter Breitenlohner wrote:

> There are no tests for ObjC, thus none for ObjC++ either.  I think
> eventually some such tests should be added.

Hi Eric,

I forgot: in order to verify the basic functionality (*) I have constructed
the attached tiny toy package.

(*)
(1) configure tests using ObjC++ (config.log shows *.mm testfiles)
(2) substitution of OBJXX* make vars

Regards
Peter


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Peter Breitenlohner]

On Wed, 22 Jul 2009, Peter Breitenlohner wrote:

> On Wed, 22 Jul 2009, Peter Breitenlohner wrote:
>
>> There are no tests for ObjC, thus none for ObjC++ either.  I think
>> eventually some such tests should be added.
>
> Hi Eric,
>
> I forgot: in order to verify the basic functionality (*) I have constructed
> the attached tiny toy package.
>
> (*)
> (1) configure tests using ObjC++ (config.log shows *.mm testfiles)
> (2) substitution of OBJXX* make vars

this time with the toy package.

Regards
Peter

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Peter Breitenlohner on 7/22/2009 12:46 AM:
> On Tue, 21 Jul 2009, Eric Blake wrote:
>
>> Seconded, especially since autoconf already has ObjC and C++ support, so
>> you have two similar languages to borrow from.
>
> Hi Eric,
>
> attached is a patch implementing autoconf support for ObjC++.  As expected
> this was extremely straightforward and only marginally intrusive.

In general, I'm in favor of this patch, but you are right that it would be
nice to have some testsuite exposure to go along with it.  I have not yet
tested it much.  Also, let's make sure we don't repeat the C++ mistake -
if no suitable ObjC++ compiler is found, please make sure OBJCXX is set to
no, not g++.  (I didn't check if you did that).

> Maybe the patch is still in time for 2.64.  That would be very helpful for
> the Automake part of all that.  Attempting to implement automake support
> for
> ObjC++ without a released autoconf version providing the basics would be
> rather awkward.

I've already explained off-list why I think this patch is not in time, at
least not if I am able to release 2.64 this week as planned.  Sorry about
that.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEUEARECAAYFAkpoX6QACgkQ84KuGfSFAYAQTgCfaNI8PnjMOwuTUhCUolo7AqpX
DvUAmJH+ZGGgxToduPxyfkqtZX5Iaxk=
=gI5W
-----END PGP SIGNATURE-----


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Peter Breitenlohner]

On Thu, 23 Jul 2009, Eric Blake wrote:

> In general, I'm in favor of this patch, but you are right that it would be
> nice to have some testsuite exposure to go along with it.

Hi Eric,

agreed. I'll think about some very basic tests for both ObjC and ObjC++.
However, there really isn't that much to be tested in the autoconf part.

> ....  Also, let's make sure we don't repeat the C++ mistake -
> if no suitable ObjC++ compiler is found, please make sure OBJCXX is set to
> no, not g++.  (I didn't check if you did that).

I'll have to check, and if necessary correct it (if so for both ObjC and
ObjC++).

> I've already explained off-list why I think this patch is not in time, at
> least not if I am able to release 2.64 this week as planned.

In that case there has to be AM_PROG_OBJCXX from automake together
with AU_DEFUN([AM_PROG_OBJCXX], [AC_PROG_OBJCXX]) from autoconf or similar.

Regards
Peter


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Peter Breitenlohner]

On Thu, 23 Jul 2009, Eric Blake wrote:

> ....  Also, let's make sure we don't repeat the C++ mistake -
> if no suitable ObjC++ compiler is found, please make sure OBJCXX is set to
> no, not g++.  (I didn't check if you did that).

Hi Eric,

although I remember having seen this (for C++) on the automake list, I am thoroughly
puzzled, because I couldn't find anything related in c.m4 (from git).
Moreover, I just did a small test using
  AC_PROG_CXX([gxx])
with no gxx in my PATH resulting in CXX=g++.

Did I miss something?

Regards
Peter


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Peter Breitenlohner on 7/22/2009 12:46 AM:
> attached is a patch implementing autoconf support for ObjC++.  As expected
> this was extremely straightforward and only marginally intrusive.

I've applied it with only minor modifications (for merge conflict
resolution), and would appreciate you checking that it still works well
with your pending automake patch.

> There are no tests for ObjC, thus none for ObjC++ either.  I think
> eventually some such tests should be added.

Agreed, but as I am less familiar with ObjC++, I'm hoping you'll help fill
in some of the gap, here.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqvhAwACgkQ84KuGfSFAYA8xwCfbW5N9GlPobbl5jQFKDkBC++j
H8gAniSh1CO5ed0qK0gkvIIBSxi31GSD
=9Yak
-----END PGP SIGNATURE-----


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Peter Breitenlohner]

On Tue, 15 Sep 2009, Eric Blake wrote:

> According to Peter Breitenlohner on 7/22/2009 12:46 AM:
>> attached is a patch implementing autoconf support for ObjC++.  As expected
>> this was extremely straightforward and only marginally intrusive.
>
> I've applied it with only minor modifications (for merge conflict
> resolution), and would appreciate you checking that it still works well
> with your pending automake patch.

Hi Eric,

thanks. I'll look into this during one of the next days.  The only merge
conflict I saw were, however, just lines preceding the actual change.

>> There are no tests for ObjC, thus none for ObjC++ either.  I think
>> eventually some such tests should be added.
>
> Agreed, but as I am less familiar with ObjC++, I'm hoping you'll help fill
> in some of the gap, here.

Well, my knowledge of ObjC and ObjC++ might be even more limited (my main
interest is the TeXlive build system that uses such files -- if and only if
building for darwin).

Anyway, it may be difficult to cook up ObjC and ObjC++ examples that can be
compiled and linked with all sort of compilers (on darwin as well as
non-darwin systems).  But as a minimal test one might ensure that the
switching to/from ObjC++ works (as now in '260: AC_LANG_OBJC' under 'Testing
autoconf/c macros') and that the appropriate variables get substituted or
some such.

I must, however, admit that I don't understand where the majority of these
tests originate.  This mostly looks quite miraculous to me.

Regards
Peter Breitenlohner <peb@...>


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

* Peter Breitenlohner wrote on Tue, Jul 21, 2009 at 11:26:15AM CEST:
> During the last several months I was involved in a complete rewrite of
> the TeXlive (formerly teTeX) build system using Automake and modernized
> Autoconf.
>
> In doing so I "had" to use the names of various cache variables, in order to
> write, e.g.
[...]
> It would be nice if these ac_cv_* names could be made part of the API, i.e.,
> be frozen and documented.

This has been done recently, for many cache variables.  I failed to see
this message at that time (wrong Subject ;-) so didn't list you as bug
reporter.

Cheers,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Peter Breitenlohner]

On Wed, 7 Oct 2009, Ralf Wildenhues wrote:

> This has been done recently, for many cache variables.  I failed to see
> this message at that time (wrong Subject ;-) so didn't list you as bug
> reporter.

Hi Ralf,

attached is a tiny patch correcting a small typo in the heading for this new
index.

Regards
Peter Breitenlohner <peb@...>
From 79754666d92e4aa9325a41e3495a98c2c13c9580 Mon Sep 17 00:00:00 2001
From: Peter Breitenlohner <peb@...>
Date: Wed, 14 Oct 2009 10:41:45 +0200
Subject: [PATCH] typo in cache variable index


Signed-off-by: Peter Breitenlohner <peb@...>
---
 doc/autoconf.texi |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index fd76150..d5c001d 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -24612,7 +24612,7 @@ use these names in @code{#if} or @code{#ifdef} directives.
 @appendixsec Cache Variable Index
 
 This is an alphabetical list of documented cache variables used
-by macros defined in Autoconf.  Autoconf macro may use additional cache
+by macros defined in Autoconf.  Autoconf macros may use additional cache
 variables internally.
 @ifset shortindexflag
 To make the list easier to use, the variables are listed without their
--
1.6.4


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Peter Breitenlohner]

On Wed, 14 Oct 2009, Peter Breitenlohner wrote:

> On Wed, 7 Oct 2009, Ralf Wildenhues wrote:
>
>> This has been done recently, for many cache variables.  I failed to see
>> this message at that time (wrong Subject ;-) so didn't list you as bug
>> reporter.
>
> attached is a tiny patch correcting a small typo in the heading for this new
> index.

Hi Ralf,

here now another patch correcting the description for ac_cv_search_FUNC.

Regards
Peter Breitenlohner <peb@...>
From d1e598832788f8b95068fb5f61e50fc297e8eff6 Mon Sep 17 00:00:00 2001
From: Peter Breitenlohner <peb@...>
Date: Wed, 14 Oct 2009 12:19:32 +0200
Subject: [PATCH 2/2] description of ac_cv_search_FUNC


Signed-off-by: Peter Breitenlohner <peb@...>
---
 doc/autoconf.texi |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index d5c001d..4685972 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -4428,7 +4428,8 @@ that @var{function} is present, because linking the test program
 always fails with unresolved symbols.
 
 The result of this test is cached in the
-@code{ac_cv_search_@var{function}} variable as @samp{no}, if no library
+@code{ac_cv_search_@var{function}} variable as @samp{none required} if
+@var{function} is already available, as @samp{no} if no library
 containing @var{function} was found, otherwise as the
 @option{-l@var{library}} option that needs to be added to @code{LIBS}.
 @end defmac
--
1.6.4


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Peter Breitenlohner on 10/14/2009 4:24 AM:
>
> here now another patch correcting the description for ac_cv_search_FUNC.

Thanks; I squashed the two fixes into one commit, added a ChangeLog, and
applied.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrXEroACgkQ84KuGfSFAYByfwCgyaDGgEoq+QnYRcXsSNbpB/H6
HQkAmwW6OgxNdZylc6BCfFTPWsVV7CIZ
=QIEZ
-----END PGP SIGNATURE-----


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Peter Breitenlohner]

On Thu, 15 Oct 2009, Eric Blake wrote:

> Thanks; I squashed the two fixes into one commit, added a ChangeLog, and
> applied.

Hi Eric,

thanks.

----------------

I'd like to report two more Autoconf problems. Both are, however, uncritical
and should not delay the release of 2.65.

---------

(1) Some time ago I mad a mistake and wrote

AC_ARG_WITH([yyy=DIR],
             AS_HELP_STRING([--with-yyy],
                            [Use DIR for ...]))
instead of

AC_ARG_WITH([yyy],
             AS_HELP_STRING([--with-yyy=DIR],
                            [Use DIR for ...]))

with fairly strange results and hard-to-interprete error/warning messages.
IMHO the macros AC_ARG_{WITH,ENABLE} ought to either check or sanitize their
first argument.

---------

(2) I use a multi-line output variable to generate a complete make rule,
i.e., something like

RULE='TARGET: DEPENDENCIES
  COMMAND'
AC_SUBST([RULE])
AM_SUBST_NOTMAKE([RULE])

in configure.ac and

@RULE@

in Makefile.am, and this nicely generates rules used to rebuild other parts
of the tree.

There is, however, a minor problem: The list of output variables in
config.log is sorted after expanding all variables with a rather unwanted
effect on multi-line values.  This isn't really a problem except when
debugging complex macros.

I think the code, in general.m4 starting with AS_BOX([Output variables.]),
could easily be modified to first sort the variable names and insert their
values afterwards.

----------------

Regards
Peter Breitenlohner <peb@...>


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf