On Mon, Aug 10, 2009 at 10:12 AM, Simon Josefsson<si...@josefsson.org> wrote: > Sam Steingold <s...@gnu.org> writes: > >> Some packages are compilable with both C (production) and C++ (extra >> compilation time type checking and run-time verification for >> debugging). >> when such a package uses code from gnulib, it wants to compile it with >> the compiler ($(CC)) it uses for the rest of the package, i.e., when >> compiling with CC=C, it compiles the imported gnulib code with C, ahen >> compiling with CC=C++, it compiles the imported gnulib code with with >> C++. >> when the imported gnulib code cannot be compiled with C++ (e.g., >> regexp), this causes problems. > > I don't see how CC=c++ would ever work generally as C and C++ are > different languages.
well, they are similar enough that their common part, if you wish (i.e., the code that would compile with both) is large enough for a package to be written in. after all C++ was designed as an extension to C, i.e., originally it was a superset thereof. > Instead of CC=c++, why not use a configure parameter like > --with-cxx-compiler that makes the project build the parts of the > project that is known to be compilable as C++ using the system's C++ > compiler, and use a C compiler for the rest (i.e., gnulib code)? With > this approach, you can use normal AC_PROG_CXX etc checks for the C++ > stuff and don't have to hack around autoconf/automake. what is --with-cxx-compiler? how do I enable it? >>> Compiling C code with a C++ compiler seems like a good recipe for >>> problems, and I don't think it is something gnulib should force on users >>> unless there is a compelling use-case. >> >> the "forcing" goes the other way around. >> the user of gnulib forces C++ on gnulib code, and gnulib should use >> no-cxx (when necessary) to cope with it. > > I don't follow the analogy. If a user attempts CC=python gnulib will > break. I did not know python was designed as a superset of C. > Is there a wide class of projects or operating systems that recommends > or suggests use of CC=c++ that I've missed? I'm trying to understand > the origins of the CC=c++ notion. Learning that may help me understand > the bigger picture. http://clisp.cons.org/impnotes/gc-safety.html#gc-alloccount -- Sam Steingold <http://sds.podval.org>
