bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: no-c++


From: Simon Josefsson
Subject: Re: no-c++
Date: Mon, 10 Aug 2009 16:12:50 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux)

Sam Steingold <address@hidden> writes:

> On Mon, Aug 10, 2009 at 6:28 AM, Simon Josefsson<address@hidden> wrote:
>> Bruno Haible <address@hidden> writes:
>>
>>> Should the 'regex' module (and possibly other modules which require C
>>> syntax) depend on the 'no-c++' module? We can open a poll on it.
>>
>> I don't understand the rationale for the no-c++ module, let alone making
>> any other modules depend on it.
>>
>> What is the issue with compiling C code with a C compiler and C++ code
>> with a C++ compiler?  That seems to be me the proper solution.
>
> 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.

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.

>> 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.  The right solution seems to me be to tell the user to stop doing
that, rather than trying to work around it (e.g., adding flags to the
python interpreter to make it parse C).  I don't follow how this differs
from your CC=c++ situation, except that C and C++ looks (to a human)
more similar compared to C and Python.

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.

/Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]