[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] The carnivorous config bug

From: Christian Gagneraud
Subject: Re: [gpsd-dev] The carnivorous config bug
Date: Fri, 01 Nov 2013 10:09:34 +1300
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0

On 01/11/13 06:12, Eric S. Raymond wrote:
I was so burned out last time I posted that I forgot to actually
describe the carnivorous config bug. It goes like this: if you
"scons -c", then do not nuke the scons cache with "rm -fr .sc*",
some but not all feature tests will spuriously fail (that is, return
"no" when they should return "yes").

There's another bug as well in the Sconstruct file that I reported a month or 2 ago, it relates to the static vs dynamic linking, and the order programs are built (gcc will do dynamic linking if the .so is built before the .a). The most anoying consequence is that the linking process is not repeatable and breaks when using parallel builds. [For some unknown reasons, I couldn't find these emails on the ML archive...]

Another minor bug, is the build of the python bindings that doesn't pickup the project CFLAGS & co.

I would like to add other things to the list of configuration system issues:
- I'm about to send an RFC for the code coverage, as you will see it requires lot of modifications to collect the coverage data while executing the tests, this will have to be addressed - Regression tests take time to execute because there are executed sequentially, it would be nice if they could be executed in parallel (especially raw-regress)

One of the spurious failures will be the test for TIOCMWAIT.  That
failure will force pps off.  Hilarity ensues if you're trying to fix
PPS-related bugs.  I missed this for two days because the config lines
tend to scroll out of view really fast.

What about using colors in the output, would it help to highlight the important parts? What about a "scons configure" command?


So, if you scons -c to clear your build state, nuke the scons cache
with "rm -fr .sc*", too.

I don't know whether this is a bug in core scons or a specific problem
with the Configure extensions. I suspect the latter.

I've sent a bug report to the scons-users mailing list.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]