setting CFLAGS in /etc/make.conf

Ruslan Ermilov ru at
Fri Aug 20 02:33:42 PDT 2004

On Fri, Aug 20, 2004 at 10:44:58AM +0200, Oliver Eikemeier wrote:
> I have a problem with the following recommendation in 
> src/share/examples/etc/make.conf:
> # CFLAGS controls the compiler settings used when compiling C code.
> # Note that optimization settings other than -O and -O2 are not 
> recommended
> # or supported for compiling the world or the kernel - please revert any
> # nonstandard optimization settings to "-O" before submitting bug reports
> # without patches to the developers.
> # Note also that at this time the -O2 setting is known to expose bugs in
> # libalias(3), and possibly other parts of the system.
> #
> #CFLAGS= -O -pipe
> Basically, when a port tries to pass CFLAGS to the distribution 
> Makefile, this is done by
>   env CFLAGS="${CFLAGS}" make
> which is effectively overwritten by users setting CFLAGS in 
> make.conf(5). OTOH when += is used, it inherits the previous values, so 
> when someone would do
> CFLAGS+=	-O -pipe
> in make.conf(5) the effective value passed is "-O -pipe -O -pipe 
> ${_CPUCFLAGS}", which is not harmful, but not good either. This is 
> especially problematic when the port uses CFLAGS="${PTHREAD_CFLAGS}" or 
> CFLAGS="-DMY_OPTION", and a lot of ports use CFLAGS. This is no problem 
> when the port has USE_GMAKE, since gmake doesn't read make.conf(5).
> The following Makefile illustrates the problem:
> all:
> 	@env CFLAGS="${CFLAGS} -DFOO" ${MAKE} cflags
> .ifmake cflags
> CFLAGS+=        -DBAR
> .endif
> cflags:
> with the output:
> Basically this is the expected result, although the ${_CPUCFLAGS} is 
> unfortunately doubled.
No, this is an abuse of the intended CFLAGS usage.  CFLAGS is
the add-only variable by design.  You shouldn't reuse its
value to reinitialize it.

> This is what a typical port would see. When I now 
> set
> CFLAGS=	-O -pipe
> in make.conf(5), which is the example given in 
> share/examples/etc/make.conf, I get:
> so I loose the settings done in the ports Makefile (-DFOO).
Just to make the picture clear for the rest of the readers.
This has nothing to do with recent changes to make(1), this
behavior of CFLAGS was forever.  Since global variables are
of a higher precedence than envieronment variables, the
unconditional CFLAGS setting from /etc/make.conf takes
precedence of CFLAGS specified in environment.  That
explains what you're seeing (and you well understand it,
I'm sure).

> One solution would be to set __MAKE_CONF=/dev/null in, 
> another solution is to deprecate setting CFLAGS in make.conf(5), or use 
> an alternate variable.
Both aren't good.  People may have something set in /etc/make.conf
for a good reason, e.g. to influence the build of some ports, for
example.  Also, you cannot "deprecate" unconditional (with the `='
operator) setting of CFLAGS in /etc/make.conf, as this is a well
established practice, so there will always be someone who sets it
this way.

> Generally I believe it is unexpected that an reexecution of make(1) 
> overwrites CFLAGS explicitly passed in the environment, so deprecating 
> its usage is my favorite option here. Btw, passing CFLAGS in the command 
> line is not an option, since Makefiles need to be able to add to the 
> value.
> Thoughs?
I suggest another solution: modifying the distribution makefile
when needed, by adding the CFLAGS+=-DFOO onto the top of it, or
doing something equivalent.  This works most reliable:

Port's main makefile:

: all:
: 	# commands that modify the distribution makefile
: 	@${MAKE} cflags

Distribution makefile:

: CFLAGS+=	-DFOO	# this line was added by the port's makefile
: .ifmake cflags
: .endif
: cflags:

An equivalent thing that doesn't involve modifying the distribution
makefile would be:

Port's main makefile:

: all:
:         @cd ${WRKDIR} && ${MAKE} -f Makefile.wrapper cflags

Ports produced makefile (Makefile.wrapper) in WRKDIR:

: .include "Makefile"

Distribution's original makefile (Makefile):

: .ifmake cflags
: .endif
: cflags:

Ruslan Ermilov
ru at
FreeBSD committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :

More information about the freebsd-current mailing list