Hacker News new | past | comments | ask | show | jobs | submit login

The build system should encapsulate everything needed to build the software, ideally with a single standard command. If your build system requires you to manually run build steps before or after it, your build system is broken (cmake unfortunately also often falls down in this regard, especially for cross-compiled projects).



So it's fine for you to have to manually run a sequence of steps (start your computer, open a terminal, navigate to the project, run the build, run the program), but it's unbearable if the build is split in a couple commands?

I don't get it. Also shell scripts are pretty good at running a couple commands, if really that's important.


If you start using shell scripts, you are throwing away the whole advantage of build systems, which is only rebuilding what is necessary. Using multiple manual build phases (even if you have a shell script calling them all) also increases contributor friction and is terrible for FLOSS.


Well, I run the scripts only when necessary. If I change an IDL file, I run the generation script. If I change a cpp file, I run the cmake build only.

I actually have maintained FLOSS projects, and in my experience, throwing everything in one cmake project makes it harder for contributors to understand. Because they only ever use one command, and the day something fails they have to dig into it to understand what that custom command does. On the contrary, if they need to run the generation script first, then they know that there is a generation step involved, and suddenly the whole thing feels less like magic.

So that is my opinion: if your FLOSS project uses a big custom build system (because you customized your cmake to do all sorts of custom things), then probably I will not contribute. Because I have other things to do than learning your custom integration of standards steps I actually would already know.


Why do you feel it's better to do the build system's job manually? I've seen beginners interact with such a system and it's a recipe for even more confusion.


> Why do you feel it's better to do the build system's job manually?

What's better is what is easier to understand and maintain. If your whole project is made of one file and builds with one simple call to a compiler, IMO it's fine to just have this line in the README, no need for a custom_target in cmake.

Now the thing is that often, I see that people put a lot of importance into the "it should be easy to get started for beginners who don't know the tools", and everything is glued together using some custom functions. The goal being that a beginner can essentially run "make" (yep, I've seen Makefiles wrapping CMakeLists for that) and the project will build (sometimes it will even install dependencies on the system, that's crazy). But then if the beginner wants to understand what's happening under the hood, well... it's a big pile of custom glue.

Now if, instead of that, you document the tools you are using in your README, and use the tools in a standard way, then people who know the tools will get started quickly ("oh, it's protoc then cmake, I know exactly how to use that"). And yeah, beginners will need to learn how to run those tools. But that's fine IMO, because if you use the tools the standard way (without custom functions), then the beginner can just look for the official docs.

Standard is better than custom.


I don't want to have to find out about and remember a bunch of different commands, and I especially don't want the risk that I get into an inconsistent state by forgetting a step when something changes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: