4 ms·

I don't think a single build system is necessary or desirable. meson (as well as waf and scons) depends on python, which is not so nice for bootstrapping. Thus

I don't think a single build system is necessary or desirable. meson (as well as waf and scons) depends on python, which is not so nice for bootstrapping. Thus desktop applications and low level userspace plumbing could benefit from different build systems. That said, I hope waf and scons die off soon (only a handful of packages even use them). CMake and Meson are much better choices.

bogwog 6y ago
What’s wrong with waf? I’ve been using it lately and think it’s great. Writing build complex build tasks is easy, and the performance is excellent. I haven’t tried Meson, but CMake cant really do much besides compile the programming languages it explicitly supports. Automation tasks are pretty much impossible.
- CameronNemo 6y ago
  Do you have a link to these wscripts, or a pastebin? I am curious on what types of automations you are referring to. I'm mainly coming at it from the perspective of a distro maintainer. Few pieces of software use waf, and digging into the wscripts can be a pain for large projects. Only having to know a half dozen build systems is way easier than having to know waf, Scons, meson, autotools, make, setuptools, cargo, qmake, cmake is a pain. Only 25 packages in the distro I contribute to use waf. Most are audio recording tools that do not get much maintenance. 20 packages use scons. Meanwhile almost 400 use meson, ~500 use qmake, ~1000 use cmake, and over 2000 use autotools.
  - bogwog 6y ago
    > Do you have a link to these wscripts, or a pastebin? I am curious on what types of automations you are referring to. Not currently, but I do have a half-written article I plan to publish eventually once I complete this project I'm working on, to showcase my use of waf and how it's helped me. That's how much I like it! But to give you a quick example: my project (a cross-platform game) has a bunch of assets that I am embedding in the executable. To do this, I wrote a custom waf task that automatically generates a char array in a .cpp/.h bundle, and adds it to my build and include paths. Using that same tool, I am able to embed other assets that need to be transformed in various ways before being embedded. One of those is a bundle of binary files and meta-data combined together inside a single flatbuffer data blob. This involves compiling the schema, generating a small command-line utility to write the blob using the sources generated from the schema compiler, using that utility to generate the blob, and finally embedding the blob using the asset embedding tool. (Plus some of the binary files themselves need to be processed before all of this happens) I could do that with shell scripts, but waf's design makes it easy to do, in a small amount of reusable code (everything I just described I implemented in <400 lines of python), and in a general-purpose and easy to read programming language. Plus the tasks automatically execute in parallel wherever possible. > I'm mainly coming at it from the perspective of a distro maintainer. Few pieces of software use waf, and digging into the wscripts can be a pain for large projects. I've heard that complaint before, and I can see why it would be annoying for outside maintainers. Waf's customizability means two Waf projects might look nothing alike. So even if one becomes an expert at Waf (which is not very easy considering how bad the docs are), they might be completely lost in someone else's project. I failed a game jam once because I was using Amazon Lumberyard (which uses waf), and even though I completed the game, I couldn't figure out how to compile the damn thing before the deadline. But if it's any consolation, I don't plan on distributing my project through any linux distros :P
    - Arelius 6y ago
      Having used WAF extensively in large legacy projects, one of it’s large problems is that it isn’t particularly batteries included, and relies on a lot of customizations, and doesn’t have a lot of rails so it’s really easy to break it’s reliability guarantees. And having a unreliable build where one is never sure if a problem will go away by deleting intermediates is super frustrating.
amelius 6y ago
> I don't think a single build system is necessary or desirable. Why not? In the old days, it was "./configure; make". Today, it's much less certain what build system(s) you'll have to deal with when building a FOSS tool. That's not a problem when everything works, but as experience shows, more often than not you'll run into issues and then I would say it's nice if you are familiar with the system. And just like with other tools it's nice if everybody uses the same thing. Github wouldn't exist if everybody rolled their own version control system, for example.
- progval 6y ago
  > Github wouldn't exist if everybody rolled their own version control system, for example. It also wouldn't exist if no one did. It's all about compromises. Having too many tools for the same job isn't good, but monoculture isn't either.
nonbirithm 6y ago
If Cargo didn't exist I would believe you. But a group of people learning from past mistakes and doing most of the things right from the start has convinced me otherwise. Sadly when it comes to C++ I don't think we'll get a do-over. Too many build systems exist already, and important libraries from a decade or two ago will use those systems until the end of time, and so will the projects that depend on them indirectly.

bogwog 6y ago

What’s wrong with waf? I’ve been using it lately and think it’s great. Writing build complex build tasks is easy, and the performance is excellent. I haven’t tried Meson, but CMake cant really do much besides compile the programming languages it explicitly supports. Automation tasks are pretty much impossible.

CameronNemo 6y ago
Do you have a link to these wscripts, or a pastebin? I am curious on what types of automations you are referring to. I'm mainly coming at it from the perspective of a distro maintainer. Few pieces of software use waf, and digging into the wscripts can be a pain for large projects. Only having to know a half dozen build systems is way easier than having to know waf, Scons, meson, autotools, make, setuptools, cargo, qmake, cmake is a pain. Only 25 packages in the distro I contribute to use waf. Most are audio recording tools that do not get much maintenance. 20 packages use scons. Meanwhile almost 400 use meson, ~500 use qmake, ~1000 use cmake, and over 2000 use autotools.
- bogwog 6y ago
  > Do you have a link to these wscripts, or a pastebin? I am curious on what types of automations you are referring to. Not currently, but I do have a half-written article I plan to publish eventually once I complete this project I'm working on, to showcase my use of waf and how it's helped me. That's how much I like it! But to give you a quick example: my project (a cross-platform game) has a bunch of assets that I am embedding in the executable. To do this, I wrote a custom waf task that automatically generates a char array in a .cpp/.h bundle, and adds it to my build and include paths. Using that same tool, I am able to embed other assets that need to be transformed in various ways before being embedded. One of those is a bundle of binary files and meta-data combined together inside a single flatbuffer data blob. This involves compiling the schema, generating a small command-line utility to write the blob using the sources generated from the schema compiler, using that utility to generate the blob, and finally embedding the blob using the asset embedding tool. (Plus some of the binary files themselves need to be processed before all of this happens) I could do that with shell scripts, but waf's design makes it easy to do, in a small amount of reusable code (everything I just described I implemented in <400 lines of python), and in a general-purpose and easy to read programming language. Plus the tasks automatically execute in parallel wherever possible. > I'm mainly coming at it from the perspective of a distro maintainer. Few pieces of software use waf, and digging into the wscripts can be a pain for large projects. I've heard that complaint before, and I can see why it would be annoying for outside maintainers. Waf's customizability means two Waf projects might look nothing alike. So even if one becomes an expert at Waf (which is not very easy considering how bad the docs are), they might be completely lost in someone else's project. I failed a game jam once because I was using Amazon Lumberyard (which uses waf), and even though I completed the game, I couldn't figure out how to compile the damn thing before the deadline. But if it's any consolation, I don't plan on distributing my project through any linux distros :P
  - Arelius 6y ago
    Having used WAF extensively in large legacy projects, one of it’s large problems is that it isn’t particularly batteries included, and relies on a lot of customizations, and doesn’t have a lot of rails so it’s really easy to break it’s reliability guarantees. And having a unreliable build where one is never sure if a problem will go away by deleting intermediates is super frustrating.

amelius 6y ago

> I don't think a single build system is necessary or desirable. Why not? In the old days, it was "./configure; make". Today, it's much less certain what build system(s) you'll have to deal with when building a FOSS tool. That's not a problem when everything works, but as experience shows, more often than not you'll run into issues and then I would say it's nice if you are familiar with the system. And just like with other tools it's nice if everybody uses the same thing. Github wouldn't exist if everybody rolled their own version control system, for example.

progval 6y ago
> Github wouldn't exist if everybody rolled their own version control system, for example. It also wouldn't exist if no one did. It's all about compromises. Having too many tools for the same job isn't good, but monoculture isn't either.

nonbirithm 6y ago

If Cargo didn't exist I would believe you. But a group of people learning from past mistakes and doing most of the things right from the start has convinced me otherwise. Sadly when it comes to C++ I don't think we'll get a do-over. Too many build systems exist already, and important libraries from a decade or two ago will use those systems until the end of time, and so will the projects that depend on them indirectly.