gpsd-dev
[Top][All Lists]
Advanced

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

Re: would it be time to replace scons with meson build system?


From: Greg Troxel
Subject: Re: would it be time to replace scons with meson build system?
Date: Wed, 05 Feb 2020 09:26:22 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix)

"Eric S. Raymond" <address@hidden> writes:

> Greg Troxel <address@hidden>:
>> scons feels like it is diffficult to deal with, and that it is starting
>> to be used by very few projects.
>> 
>> SConstruct has 2345 non-comment non-blank lines.   I think that makes it
>> difficult to deal with.
>
> I might not have made this clear before. I am willing for scons to be
> replaced.  It was my choice originally, and I still think a good choice given
> that we couldn't know the future - but it has stagnated.

Thanks for saying that.   If one accepts that replacing autoconf was the
right thing, then scons did seem like a good choice at the time.
Actually I'm not sure there were other viable options.

I meant to say that many years later, the landscape has changed, and
scons seems to not have a lot of mindshare, and now there are other options.

> I don't have any opiniomn about what to replace it with, other than
> *not autoconf*.

I think we need to talk about what we need in a build system, and some
of that is:

  - works on any reasonable basically-POSIX system

  - there is no requirement for native Windows builds, and perhaps no
    requirement for Windows at all.

  - has a relatively compact expression of build rules, which more or
    less means declarative rather than writing code to do builds

  - has a track record of being maintained, and enough usage by other
    projects that there is a reasonable expectation that the build
    system will continue to be a reasonable choice for 5 years, and
    ideally longer

  - doesn't impose difficult requirements beyond what gpsd does already
    (e.g., needing C++11 for a build tool would be bad)

  - has a notion of feature tests, rather than ifdefing per operating
    system, and promotes a culture of doing it that way

  - supports setting prefix, and enabling/disabling options, etc.

  - supports dealing with -L/-R flags as expected on a variety of systems

  - supports running tests

  - supports running the just-built code before installing so that it
    uses the built libs and does not pick up the already-in-system libs
    (necessary for tests)

  - supports cross compiling

  - supports building placing the objects not in source tree

  - supports creating distfiles

  - supports testing the created distfile by unpacking it, doing an
    out-of-source build and then running tests

Of course, parts of all of the above can happen by configuration within
the build system files, vs true native support, but the point is that
all of things have to be reaosnably easily and reasonably non-kludgily
doable.

This rules out cmake, which needs C++11, and for me, has a personal
track record of having difficulty building it due to tracking C++
features way too fast.  And, (perhaps this is unfair) cmake-using
projects tend to have a lot of code in CMakefiles that has per-OS ifdefs
when they should have feature tests.

Qbs is from the QT world, and seems to need javascript (which isn't as
bad as C++, probably).  It seems that QT itself is no longer using it.
The wikipedia list of "notable projects" using it is very short.
Perhaps not fair, but I had never heard of it.  There's also the issue
that QT is a world that is either just barely or not quite really Free
Software; I've recently heard that some usages will require non-free
licenses, and of course there was the issue long ago with not-quite-free
licenses.  Qbs is not in pkgsrc, which is a not-100%-reliable clue that
it is not important in the large Free Software ecosystem.  So I really
don't see how this can be seriously considered.

I am unfamiliar with meson, which is relatively new.  But gtk seems to
have switched to it, and it's in python (which isn't a leap compared to
gpsd needs, and python is quite portable and easy to deal with).  So it
might be ok.



reply via email to

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