Re: [gpsd-dev] Changing build systems

[Eric S. Raymond]

Bernd Zeimetz <address@hidden>:
> I'm just the one who complains loudly. The others just mail me or
> message me and say that I'm not the only one who thinks that scons
> is not usable in its current state.

We know scons is "usable in its current state" because we *use* it; I
have shipped many successful releases with it.

Don't exaggerate like that; you damage your ability to get valid
criticisms taken seriously when you do.  If you want to say there are,
in your opinion, crucial missing features and things it should do
better, then you should say that and I will listen - but claiming it
is "not usable" is so obviously wrong that it just makes you sound
irrational and causes me to tune you out.

Now I want you to notice something.  You have complained a lot about
things that scons doesn't do well enough - missing features.  Some of
those complaints have merit, and I'm going to go pound on the SCons
maintainers until I see some movement.  What you have not done is
identified any case in which scons supports a feature and *gets it
wrong*. You should think hard about that.

> For starters:
> - Handle versioned shared libraries probably. Know what sonames are
> and what the other numbers are used
> for. https://autotools.io/libtool/version.html has a description.

It is possible they may already have solved this, but the
documentation is too bad for it to be usable.  The documentation is at
the top of my list of things they *must* fix, and I will beat them up
until they do it.  What's there now is inexcusably poor.

> - Build shared and static libraries at the same time.

Reasonable, though probably tricky.  I will pursue this.

> - Handle cross building without having to specify all tools you want to use -
> specifying the target architecture should be enough.

I don't think this goal is realistic; there's still too much toolchain
variation.  But I know someone who routinely does cross-builds for OpenWRT;
I will discuss it with him.

> - Handle  stuff like importing flags from the environment. We have crap like
> for i in ["AR", "ARFLAGS", "CCFLAGS", "CFLAGS", "CC", "CXX", "CXXFLAGS",
> "LINKFLAGS", "STRIP", "PKG_CONFIG", "CHRPATH", "LD", "TAR"]:
>     if os.environ.has_key(i):
>         ....

Reasonable, if mostly syntactic sugar.

> in SConstruct.
> - Build Python modules in a sane way.

I'm all for this, but you need to specify what the "sane way would look like.
What do you want a Python module builder to look like?  What inputs? What
environment variables would it use?

Don't just gripe.  Sketch an interface and desired behavior.  I might
actually be able to get them to do this.

> - Know about installed files and be able to uninstall them.

Fair enough.  They mostly do cover this pretty well, but there's a
small amount of nasty hair after SConstruct:1480 that I should not
have had to write.

> - Handle the rpath/chrpath issues in a sane way. WITHOUT chrpath. Re-link 
> files
> at install time or use script-wrappers like libtool. Whatever works.

Again, I can't just go to them and say "be sane".  We have to specify what we
mean by that. Sketch a design.  If you *can't* sketch a design, then maybe
the fact that this is difficult to do isn't surprising.

> - Have a working distclean.

Can you specify how this should differ from scons --clean?
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>