[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new challenges in scons cleaning, things basically ok
From: |
Bernd Zeimetz |
Subject: |
Re: new challenges in scons cleaning, things basically ok |
Date: |
Sun, 22 Dec 2019 19:03:34 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 |
On 12/22/19 4:21 AM, Gary E. Miller wrote:
>> The other maybe-problem is that the provided LDFLAGS seem not to get
>> passed to the build of this test program, resulting in it not finding
>> some gtkmm stuff. I realize that's fuzzy and will look into it post
>> release.
>
> Yeah, that can wait. As distros want to move to PIC, lto, etc, then
> LDFLAGS becomes important.
There are similar issues for CFLAGS, CPPFLAGS and others.
Scons munges and digests them into similar named, but different,
internal objects.
A bit of that mess is documented here:
commit d0e0864c2802860ff561fe0b39939b63d38b8c70
Author: Bernd Zeimetz <address@hidden>
Date: Sun Jul 28 20:46:35 2019 +0200
Fix the handling of defaults from the environment.
The way whis was handled before had various issues:
- scons' naming scheme for compiler flags is different from what we know
from autotools and (afaik) all other build systems. As it seems to
filter flags (or they are listed in the wrong environment variable and
not used at the appropriate time), most of them get lost. So far I have
not seen builds to fail becase of that.
- to make sure flags end up in the appropriate setting, use
env.MergeFlags for *FLAGS. This works well for me, but might break
special CXX/CCFLAGS settings. So far I was not able to find a better way
to handle this.
- the lower/original MergeFlags part did not work at all as
for flag in ....:
if i in os.eviron:
does not depend on the flag to be checked, but on the last checked flag
from the loop before, where i was used. As TAR is usually not in the
environment, this code was propably always dead.
- the LD/SHLINK switch was done the wrong way around and was never able
to work at all.
tl;dr: the number of newly broken things is for sure less than the
number of things that actually never worked before.
Similar issues seems to exist in the part of the code where Python build
configs are merged into the python env....
--
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
- Re: new challenges in scons cleaning, things basically ok, (continued)
- Re: new challenges in scons cleaning, things basically ok, Hal Murray, 2019/12/21
- Re: new challenges in scons cleaning, things basically ok, Gary E. Miller, 2019/12/22
- Re: new challenges in scons cleaning, things basically ok, Hal Murray, 2019/12/22
- Re: new challenges in scons cleaning, things basically ok, James Browning, 2019/12/22
- Re: new challenges in scons cleaning, things basically ok, Greg Troxel, 2019/12/22
- Re: new challenges in scons cleaning, things basically ok, Bernd Zeimetz, 2019/12/22
- Re: new challenges in scons cleaning, things basically ok, Gary E. Miller, 2019/12/22
- Re: new challenges in scons cleaning, things basically ok, Greg Troxel, 2019/12/22
Re: new challenges in scons cleaning, things basically ok, Gary E. Miller, 2019/12/21