Date: Sat, 17 Mar 2012 04:23:51 +0000 From: "b. f." <bf1783@googlemail.com> To: Jeremy Messenger <mezz.freebsd@gmail.com> Cc: freebsd-ports@freebsd.org Subject: Re: lang/lua: It does need gmake. Message-ID: <CAGFTUwON2Lm2%2BpW1FpxKjXeVY131n%2Be_sM6b%2BPNC2V=ZH-CKMA@mail.gmail.com> In-Reply-To: <CADLFttfUMNCPXGOKNfttfsWfahN2yzme42rrKOTDQFK6YMoVqw@mail.gmail.com> References: <CAGFTUwOs2ayVp3CbUt-oj0J0UWxZ-RisV6idQufwWEmxFCicQQ@mail.gmail.com> <CADLFttfUMNCPXGOKNfttfsWfahN2yzme42rrKOTDQFK6YMoVqw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/16/12, Jeremy Messenger <mezz.freebsd@gmail.com> wrote:
> On Fri, Mar 16, 2012 at 5:49 AM, b. f. <bf1783@googlemail.com> wrote:
>> Jeremy Messenger wrote:
>>> On Thu, Mar 15, 2012 at 6:23 PM, Chuck Swiger <cswiger at mac.com> wrote:
>>> > On Mar 15, 2012, at 4:18 PM, Jeremy Messenger wrote:
>>> >> Figured out. Add custom CFLAGS in the make.conf and you will get a
>>> >> build failure with make but not gmake. Here's what I have in my
>>> >> make.conf:
>>> >>
>>> >> CFLAGS= -O2 -fno-strict-aliasing -pipe -g
>>> >> STRIP=
>>> >
>>> > Does it work properly if you use "CFLAGS+=" instead?
>>>
>>> It will, but you do not need to put '+' in make.conf. I have same
>>> CFLAGS for years and years, btw.
>>
>> If you have been making these assignments unconditionally, then for
>> years and years you have been in danger of breaking or damaging the
>> builds for many ports that explicitly invoke make(1) more than once
>> (and thus read make.conf more than once), by clobbering prior changes
>> to CFLAGS or STRIP that are made in port makefiles. Despite the
>> misleading examples in the base-system example make.conf, this kind of
>> customization is not supported for Ports, and not encouraged. You
>> should take steps to ensure that your custom values are set only once,
>> before any top-level port Makefile is parsed. You can define them
>> conditionally, or move them to another makefile that is included only
>> once, or disable multiple inclusions of make.conf for Ports by using
>> something like "__MAKE_CONF=/dev/null" in the right place.
>
> Any ports have to respect the CFLAGS, see the porter handbook. If it
> fails to do then it needs to be fixed. Add '+' in the make.conf is not
> right way to do it as it's merely add in exists CFLAGS.
What we actually require is that if you pass a reasonable set of
CFLAGS to the top-level of a port build, in the environment or an
included makefile, then the port uses those flags, *with as few
additions or changes as may be necessary to successfully build the
port*. It does *not* necessarily mean that the port will only use the
user-defined CFLAGS, and very few ports do so -- most ports make
reasonable and necessary changes to the flags for parts of the port,
either in the port Makefile, the included makefiles in ports/Mk, or
the distribution makefiles. These changes may be contained in CFLAGS
or another variable, or they may be explicit. They typically include
aliasing switches, rpath instructions, changes to the search
directories for headers and libraries, parameter definitions,
PIC-related flags, etc. The fact that ports can alter CFLAGS itself
is explicitly mentioned in the Porter's Handbook, and is evident in
the ports infrastructure: ports/Mk makefiles routinely alter CFLAGS;
CFLAGS are typically passed to distribution makefiles in MAKE_ENV, not
in MAKE_ARGS, so that they will be mutable in those makefiles; etc. I
think that this should be clear to a committer of your experience.
As I wrote before, your unconditional assignment of CFLAGS in
make.conf can break or damage many ports, and you should not ask or
expect port maintainers to add unnecessary patches to ports in order
to support this unsafe practice. I already mentioned several ways in
which you can safely customize the CFLAGS (without "+=") in my
previous message.
>
> mandree, thanks for took care of it!
>
On the contrary, the port is now damaged. This is a good example of
the harmful consequences of make.conf abuse. lang/lua now confusingly
and unnecessarily passes CFLAGS to the distribution makefiles both in
the environment and on the command-line. More importantly, the
CFLAGS+= -Wall $(MYCFLAGS)
in ${WRKSRC}/src/Makefile no longer works, because adding CFLAGS to
MAKE_ARGS has made CFLAGS immutable in the distribution makefiles.
This means that the components are built without -DLUA_USE_LINUX, so
functionality has been removed from the port. This change should be
reverted.
b.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGFTUwON2Lm2%2BpW1FpxKjXeVY131n%2Be_sM6b%2BPNC2V=ZH-CKMA>