[tsc-devel] Re: Build system for TSC3

Ryan Gonzalez | Mon, 18 Jun 2018 13:26:24 UTC

On June 18, 2018 5:28:08 AM Marvin Gülker <…r@p…> wrote:

> Thank you for your suggestions. I'm going to take a look at each of them

> when I find the time. Again, don't expect me to switch anything anytime

> soon.

>

> A few comments:

>

> Am 17. Juni 2018 um 08:37 Uhr -0500 schrieb Ryan Gonzalez:

>> I'd highly advise *against* something homegrown.

>

> Rake isn't exactly "home-grown", unless you count Makefile-based build

> systems as "home-grown". Rake is basically Ruby's adaption of Make, just

> much more powerful.

>


When I say "home-grown", I'm largely referring to "we put in the compile 
commands ourself", since compiling on Windows in particular can be a hot 
mess...

>> Maintaining a custom build system on top of SCons literally killed the Yhc

>> project, and there are inevitably going to be insane portability issues on

>> less frequently used platforms.

>

> I do agree that we don't want to have a build system that causes more

> work than TSC itself. If I detect this to happen with Rake (or any other

> build system), the approach on that road is going to get cancelled.

>

>> - Meson. Now used by many GNOME and Red Hat projects (systemd, GTK+,

>> flatpak, ...) to replace the aging autotools build systems. IMO if you want

>> a meta build system (e.g. a build system generator like CMake), this is the

>> best option. It configures and builds super fast, too, and it comes with

>> built-in Boost support. Con: requires Python 3.

>

> I will take this into narrower consideration. Python 3 is getting more

> and more common, so I don't think that it is a real counter argument. It

> does depend on ninja instead of the traditional make, though, and that

> isn't as commonly installed as Python 3.

>

> What alerts me more is this (source: <http://mesonbuild.com/Quick-guide.html>):

>

>> You can also use Meson as packaged by your distro, but beware that due

>> to our frequent release cycle and development speed this version might

>> be out of date.

>

> This is the friendly rewording of "screw stable releases, screw your

> distro, and we don't care for you if you are on Debian". It looks to me

> as if it needs to cool down a little. Maybe a great project, but until

> the development speed has slowed down enough to rely on Debian's

> packaging to actually deliver a supported version, I see problems.


Well, you can pretty safely rely on the distro versions if you don't need 
the absolute newest version. For instance, systemd (and probably X11, which 
apparently also switched to Meson) basically requires the lowest common 
denominator version of Meson (which is basically 0.44, with the exception 
of Ubuntu Artful which is EOL-ing in a month).

In fact, here are the current Meson versions in various distros:

- Debian stretch-backports, Ubuntu bionic, Fedora 26 updates, 27 updates, 
28: 0.45.1 (released in March).
- Debian sid: 0.46.1 (released in May).
- Ubuntu Artful: Meson 0.42.1 (released last September). This distro is 
also EOL-ing in a month.
- CentOS 7 EPEL: Meson 0.44.1 (released in February).

They're all pretty up-to-date. AFAIK anything older than this doesn't even 
build C++11 using default packages (e.g. CentOS 6 [not sure about 7], 
Ubuntu Trusty), so TSC wouldn't be able to be packaged there anyway. FWIW 
systemd requires >= 0.44.

>

>> - Boost.Build. Idiosyncratic syntax (in master, they finally removed the

>> "space before semicolon" requirement), so-so documentation, and it's a bit

>> slower...but if you're going for pure C++ configuration support, I've never

>> seen anyone beat it.

>

> I've tried speficially to remove TSC's dependency on Boost in TSC3 as

> it's just a giant dependency. If it doesn't pull in all of boost, it

> might still be an option, though.


It's written in C and only depends on the Boehm GC.

>

>> - Waf. Used by the Samba project. I haven't used it in quite a while, but it

>> runs on many Python versions, and it's pretty fast, too.

>

> This is appearently not in Debian's repositories.


It's not supposed to be. It's a single-file script you drop in the source 
tree alongside your build script.

>

>> - Bazel. This thing is the literal definition of "fat" (depends on the JVM,

>> and the Windows binaries, bizarrely enough, include the *entire JVM*),

>> but... If you want you builds to work literally flawlessly...man, it's *so*

>> stinking nice.

>

> I think we could just use autotools if we want that kind of build system

> dependency... I don't have Java installed on my system and am not going

> to install it because some build system wants it.

>

>> - Fbuild. Ok, I'm basically the only person who uses this, but hey, this

>> list wouldn't be complete without a little plug, right? 😉

>

> Appearently not in Debian's repositories either. And if you're the only

> maintainer of it, there's a good chance that at some point you lose

> interest in working on it, which would require TSC to take it over

> entirely.

>

> Marvin

>

> --

> Blog: https://mg.guelker.eu

> PGP/GPG ID: F1D8799FBCC8BC4F

> _______________________________________________

> tsc-devel mailing list -- …l@l…

> To unsubscribe send an email to …e@l…



_______________________________________________
tsc-devel mailing list -- …l@l…
To unsubscribe send an email to …e@l…