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

[Eric S. Raymond]

Greg Troxel <address@hidden>:
> > 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.

There was one other in contention, a single-phase builder I've forgotten the 
name
of. waf and the other more modern build engines didn't exist yet.

> 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

I agree with all of those and will add "single-phase".  Means it runs
the build directly rather than generating Makefiles or (as in one
weird semi-experimental builder I stumbled over once) shellscripts.
 
> 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.

Ugh...see below.

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

If there's any possibility at all of proprietary-license entanglements,
that is a crash landing. 

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

I just learned something. From Wikipedia.

"Meson is like CMake in that it does not build software directly, but
rather sets up a backend build system such as ninja on Linux, MSBuild
on Windows or Xcode on macOS."

Two-phase build systems are evil.  That's a lesson I learned the hard
way from autoconf.  That sentence knocks out both cmake and meson for
me.

Let me be explicit about why, again: Your build errors happen in the
back end, and do not have any necessarily scrutable relationship to
the recipe you gave your front end. Troubleshooting recipes in these
systems is a pile of grief we don't need.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>