[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.
- Re: would it be time to replace scons with meson build system?, (continued)
- Re: would it be time to replace scons with meson build system?, Gary E. Miller, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Ladislav Michl, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Gary E. Miller, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Ladislav Michl, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Gary E. Miller, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Ladislav Michl, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Gary E. Miller, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Paul Fertser, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Gary E. Miller, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Paul Fertser, 2020/02/05
- Re: would it be time to replace scons with meson build system?,
Greg Troxel <=
- Re: would it be time to replace scons with meson build system?, Eric S. Raymond, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Christian Gagneraud, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Bernd Zeimetz, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Greg Troxel, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Gary E. Miller, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Claus Klein, 2020/02/07
- Re: would it be time to replace scons with meson build system?, Greg Troxel, 2020/02/07
- Re: would it be time to replace scons with meson build system?, Christian Gagneraud, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Gary E. Miller, 2020/02/05
- Re: would it be time to replace scons with meson build system?, Christian Gagneraud, 2020/02/05