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