Hacker News Reader

Could you please not use uppercase for emphasis, regardless of how much build systems annoy you? It's basically yelling, and the site guidelines ask you not to: https://news.ycombinator.com/newsguidelines.html.

Some might think, myself included, that some of the problems you are stating is caused by build system dogma, e.g. "stop building build systems, other projects aren't moving, so it makes you esoteric". Current build systems suck. It also sucks that there are so many. It's unfair that everyone has to hear that they contribute to the latter just because they want to solve the former.

What sucks more to me than finding a lib using its own build system is finding a lib that won't adopt more modern ones or languages that refuse to fix their defacto language-specific build systems, both caused by the sentiments you state about having too many and/or it being too hard for builders to change their ways. There is a middle ground here and it starts with asking software to move forward, not asking it to stop.

>PLEASE STOP BUILDING BUILD SYSTEMS.

This couls also be said about many other things as well. For example package managers and test suites. Even worse is that every language feels like they are obligated to build their own because they are obviously the best programmers on the planet (them using that language is a proof of that obviously). What results is dozens upon dozens restrictive and sub-par build systems, package mangagers and test suite that are all used by only a small group of people and are just an extra dependency for everyone else.

>It sucks when you find a smallish library and discover it uses an esoteric build system whose dependencies dwarf the library themselves (cough Yoga). The OSS community needs build system consolidation, not tacking on a 15th wheel to the cart.

Developers generally don't think of the build system as a dependency because tehy already have it installed on their own machine. Though it shoudl also be mentioned that a big portion of developers (especially those using languages that encourage to install everything with their own package manager) have a very low or no barrier for adding new dependencies.

> Relevant: http://www.rojtberg.net/1481/do-not-use-meson/

Meson is fantastic.

Except it’s a build system for C/C++ that brings in a dependency on the entire Python kitchen sink just to build a 10kb otherwise dependency-free binary.

Well, and frankly, python people shouldn't use this anyway.

The systems that I use it for all have Python installed by default, so really it's just: 'pip install meson', which takes all of a few seconds to run.

The binary it produces is still dependency free.

I’m (honestly) glad it works for you.

Distributing binaries outside of package managers is a) a rarity in the Linux world, and b) not in keeping with the open source philosophy. Requiring end users to have python so they can compile a c/c++ application will never make sense for a large portion of the user base build systems target.

It's no more egregious than requiring cmake or autotools.

And like I said, many Linux systems (and almost any used as a developers machine) will have Python installed by default.

And the simplicity of meson's build files far outweighs any issues installing it.

>The binary it produces is still dependency free.

But the project now depends on Python, pip and Meson.

As opposed to cmake or autotools?

I mean it's not like Python is a rarity on Linux systems, or a difficult thing to install (assuming it wasn't installed by default)

Python might not be rare but Meson for sure is. Cmake and autotools are very common compared to that.

Rare yes, but no more effort to install, and significantly more pleasant to use.

>contribute to or extend

I don't think it's that simple. Sure, I could spend time figuring out the GNU Make source code. I could somehow shove a C preprocessor into it and make it automatically generate dependencies based on include directives. I could make it depend on clang. Will the make maintainers accept my patch if I send it their way, though? Somehow I doubt it. What if I changed the make language to make it easy and unambiguous to write paths with spaces and other problematic characters in them? Do you think the maintainers are going to accept a patch that will most definitely break existing makefiles that work perfectly fine just because I fixed a major limitation of the program? We're talking about a tool whose grammar requires that commands be prefixed with a tab just because the author experimented with that rule and then couldn't change it because about a dozen friends were already using it. Fixing make is simply not possible at this point. If you try, it will just become yet another incompatible tool, some kind of make derivative that will have to be maintained independently. At this point, why limit yourself to make? Might as well rethink the whole thing.

As far as GNU/Linux distributions go, make and autotools are the default. If you're using anything else, it's gonna be a build time dependency that people are going to have to install in order to build your program. So you look at the other tools and you find they don't quite do what you want either. They only do about 80% of what you want, and getting it to do the remaining 20% makes you really wish the tool was an actual programming language instead of a limited build script. Is it any wonder people roll their own?

Also, I believe people should work on what they personally like. There is no obligation to contribute to some project just because it's "standard". It's an interesting problem that's difficult to solve, so it's not weird to see lots of people offering their executable opinions on how things should be done. If programmers don't like what's available out there, they are welcome to try and come up with something better. Who knows what will happen? Maybe the new wheel will turn out to be better than the current one. Maybe it won't. It might introduce new ideas that will influence new designs. These ideas might even make their way into other systems.

> I could somehow shove a C preprocessor into it and make it automatically generate dependencies based on include directives.

But the C compilers already provide tools for example `gcc -MMD`

PRs welcome

This is awful demanding. Not entirely unexpected in tech tho

“Why don’t others fix my frustration in open source projects!” they shout with no hint of irony

The FAQ basically says Windows can be supported, but only if the community manages it.

Please don't make such low-effort, insinuating, cliche comments on Hacker News. It makes the reading experience very poor.

Consider that the parent comment author might already be making pull requests to the projects of his interest. The snarky "PRs welcome" is therefore unnecessary and unwelcome. Everyone here knows PRs are welcome in an open source project. Some of us do send PRs. But whether someone sends PRs or not has no bearing on whether one can appreciate or criticize an idea as long as it is done in a substantive manner.

In fact, whether the parent comment author sends PRs or not is orthogonal to his complaint that we have too many build systems that is increasing the burden on users and maintainers. If you have something to say against this point, please do so on its own merit in a substantive manner without insinuations or ad-hominem attacks.

i'm unclear on your message. are you saying "PRs welcome" is demanding? are you saying the creators of 'please' should have contributed to bazel/buck/pants/x/y/z?

I hear you. Building this was really hard work. Open sourcing it is an achievement: the team had to navigate fraught corporate politics, untangle internal dependencies, etc. Technically it's excellent, no doubt. The site is appealing and convincing: legit kudos to whoever designed and built it.

Maybe Please is so dramatically better that it pulls tons of projects into its orbit! What a great outcome: I'd contribute PRs for every missing use case, accelerating the consolidation.

But if (as the site says) the goal is building something at parity but with a slightly different focus, then it can only produce further fragmentation. Projects that adopt Please inject dependencies on random S3 buckets and .bashrc edits. I can't accept that in the software I maintain, so any Please-built projects are de-facto inaccessible. That's bad.

By all means do what's best for ThoughtMachine, but publishing and promoting this makes building OS software harder, not easier.