[tsc-devel] Re: Build system for TSC3

Marvin Gülker | Mon, 18 Jun 2018 10:27:00 UTC

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.

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

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

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

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