[Build-common-hackers] Bug#487546: Bug#487546: cdbs: class/langcore.mk should set CC=gcc if CC is not set

[Peter Eisentraut]

On Wednesday 17 June 2009 10:32:01 Martin-Éric Racine wrote:
> On Sun, Jun 14, 2009 at 1:58 PM, Peter Eisentraut<peter_e at gmx.net> wrote:
> > On Sunday 22 June 2008 18:11:39 Martin-Éric Racine wrote:
> >> class/langcore.mk sets -g -Wall -O2 without checking whether CC can
> >> actualy process these options. For instance, -g produces output that is
> >> partially GDB-specific. On most GNU software, autotools perform these
> >> check for us and set CC=gcc autogamically. On other software, CC is
> >> often left unset. This is mostly okay on a Debian system, because the
> >> presumption is that CC=gcc, but we can never be sure of what parallel
> >> compilers, etc. someone might run, so it would be desirable for
> >> class/langcore.mk to set CC=gcc is it is unset.
> >
> > Do you have a concrete counterexample where the current code does not
> > work?
>
> In the case where an upstream tarball comes with a single C file and
> no Makefile, the only option a maintainer has is to create a manual
> build target in debian/rules to compile the binary and to include
> class/langcore.mk to always use the standard Debian build options.
> However, class/langcore.mk includes GNU-specific options without
> checking that the compiler supports them (or at least setting CC=gcc
> to ensure that it does), so the build is not guaranteed to succeed.

After further reflection, I think we should change something here.

I turns out that /usr/bin/cc is an alternative, and so we cannot assume that 
it is gcc.  And although it is not explicitly spelled out in the policy, the 
build essential list strongly hints that packages are supposed to be built 
with gcc by default.

So I think it would be easy and safe to set CC = gcc near where we set CFLAGS, 
and the same for C++.

Another advantage of this would be that packages built with cdbs don't use a 
different compiler invocation than those built without.