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
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
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,
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
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
"space before semicolon" requirement), so-so documentation, and it's a
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*
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
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
PGP/GPG ID: F1D8799FBCC8BC4F
tsc-devel mailing list -- tsc-devel(a)lists.secretchronicles.org
To unsubscribe send an email to tsc-devel-leave(a)lists.secretchronicles.org