Preventing the build from adding options like '-pipe' et al

[Valentin V. Bartenev]

On Monday 28 October 2019 18:08:28 Ralph Seichter wrote:
> * Valentin V. Bartenev:
> 
> > Could you provide a link to the policy with this requirement?
> 
> Thanks for the quick response.  [1] section "Makefile Variables" states:
> "Sometimes, badly behaved Makefile.am files will override user variables
> such as CFLAGS. This must not be allowed (...)"  [2] offers additional
> information, especially the "Not Filtering Variables" section.
> 
> I actually have open QA bugs for these build issues, so it is not me
> being overzealous.
> 
> [1] https://devmanual.gentoo.org/general-concepts/autotools/index.html
> [2] https://devmanual.gentoo.org/general-concepts/user-environment/index.html
> 

This isn't the case nighter with nginx nor with Unit.

Unit build scripts don't override user's CFLAGS.  In fact, it's constructed
out of three variables:

CFLAGS = $NXT_CFLAGS $NXT_CC_OPT $CFLAGS

http://hg.nginx.org/unit/file/tip/auto/make#l18

where:

  $NXT_CFLAGS - internal flags set by the build scripts;
  $NXT_CC_OPT - flags provided by the --cc-opt ./configure options;
  $CFLAGS - original CFLAGS from the user's environment.

It's not the case like in the example in [1]:

CFLAGS="-Wall"

Our build scripts honor user's defined CFLAGS and give them the preference
as they come after all other flags.  The user can override any of the flags
previously set if he wishes.

Note, that setting --cc-opt="${CFLAGS}" is a bad idea.  Because this way all
CFLAGS will be duplicated. 


> > I'm curious how it's solved with other ebuilds
> 
> Unless better methods are available, we usually patch autotools files
> which don't comply with Gentoo's rules. However, it is obviously much
> nicer if the upstream build process can be configured to use only the
> flags we provide at build time.

I've checked patches and ebuild files for nginx:

 - https://gitweb.gentoo.org/repo/gentoo.git/tree/www-servers/nginx

and couldn't find anything that prevents nginx from setting a bunch
of flags by default:

  -pipe  -O -W -Wall -Wpointer-arith -Wno-unused-parameter -Werror -g

nginx ebuild is maintained more than 14 years and the rhetorical question
is why it's not a problem for it, but a problem for Unit.

You've pointed out on $(MAKE), but it's another matter.  I agree to make
"make" configurable if it's required in some cases.


> 
> > It's quite normal for a build system to add some additional flags,
> > that developers see reasonable for their software.
> 
> I think that depends on the situation and/or target platform, and Gentoo
> supports some non-mainstream platforms. Forcing options like '-pipe' on
> the user which have effects during build time, or '-g' which adds debug
> symbols the user might not want, clashes with Gentoo's idea of providing
> users with the widest range (within reason) of choices.

Unit build script doesn't blindly add -pipe and -g.  The platform and compiler
are checked and relevant flags are added (different in each case).  If the
platform is unknown, then no flags are added.

We have a buildbot that builds each commit with wide range of platforms.

It's not limiting users choices, as there's an easy way to overwrite any of
these flags.

The "-g" flag is very important.  Most users don't have it by default, but
it allows to have at least some information in case of crash.  Considering
tiny size of Unit sources it adds negligible overhead to the binary.

If we won't force "-g", we will have more meaningless bug reports with all the
negative consequences.



> 
> Note that individual Gentoo developers have individual views in this
> matter, and the above is how I understand the Gentoo QA team's
> opinion. I am not a team member though, so don't take what I wrote as
> scripture. However, the Gentoo developer manual defines the rules by
> which Gentoo devs have to abide, so just ignoring the additional flags
> is not really an option I have.

Could you raise a question, what's special with Unit that additional flags
aren't allowed, while they are ok for other mature ebuilds?

With all due respect, if there's some policy then it must be equally applied
for everything, otherwise it's not really a policy, but just a matter of view
of some individual.

  wbr, Valentin V. Bartenev