gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] The carnivorous config bug


From: Eric S. Raymond
Subject: Re: [gpsd-dev] The carnivorous config bug
Date: Thu, 31 Oct 2013 20:11:49 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

Christian Gagneraud <address@hidden>:
> 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.

I think I fixed this a few days ago.  Things go wrong if you include -lgps 
in the link switches for libgpsd.

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

I see 

    python_env = env.Clone()

which looks like it ought to bring in the flags from the main environment.
Are they getting dropped in some way?

> 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

I've seen the patch.  As you say, not ready yet, but I want full
coverage audiing to be part of our normal test routine someday.  So
please keep working on it.

> - 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)

Yeah, that one would be tough, because every test wants to emit a progress
spinner.  We'd have to emit some kind of fairly elaborate queue manager to
make this work.  I doubt the pain would be worth the gain.

> What about using colors in the output, would it help to highlight
> the important parts?

It would.  We couldn't that have much explicit control of the configure 
output other than by heavily customizing the configure extension, though,
and that's another load of complexity I'm reluctant to take on.

>What about a "scons configure" command?

Much more feasible.  http://www.scons.org/wiki/SconsAutoconf includes
some incomplete but suggestive documentation on how to do this.

That's probably the direction I'll go if I can't find a fix for the bug.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>



reply via email to

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