61–70 of 74 posts
Conan + (any build system) = problem solved Conan has a learning curve, but it’s totally worth it. Anyone making their own build system should get some experience with a state of the art package manager before writing a single line of code, because chances are that it already solves whatever problem is motivating you.
I prefer the equation, :) vcpkg/NuGET + (any build system) = problem solved
Earlier quoted context omitted.
Most projects don’t have a lot of .cpp files that they don’t use :) You’re ultimately going to use them all.
Most people only change one or two files at a time. Those files, and the few that depend on them, must be rebuilt upon a change. Incremental builds only do what's necessary. Your proposal always builds everything no matter how trivial the change. It does not scale.
With large complex programs using complex incremental build systems, especially programs written in C++, you often end up spending most of your time processing the same header files over and over again. Some compilers use complex systems of pre–compiled headers that can paper over this cost, but building your whole program in a single compilation unit that only ever includes each file once eliminates it entirely without adding any additional complexity. If you want proof of this, go look at the efforts over the last year or two to shave a few minutes off the build time of the Linux kernel by carefully adjusting all of the header files, splitting them all into even smaller files so that each #include can bring in just what is needed. This avoids burdening the compiler with parsing things you aren’t going to use just to pull in a struct definition or two.
Plus, by having a single compilation unit you avoid the need to link a bunch of small object files together. Linking is the final step of building an executable, and it cannot generally be parallelized much. By reducing the amount of work the linker needs to do you can greatly speed up a step that can’t be sped up any other way.
But the real reason I recommend it is its simplicity. By spending less programmer time on the build system you can significantly reduce the overall development cost of the whole program. This is a huge benefit of Rust (and a lot of other modern programming systems) that is often overlooked. With a complex C++ program I might spend 10% of my overall development time monkeying around with the build system. If I write it in Rust I can avoid all of that; cargo can do everything I need while requiring only a very small amount of time configuring it. 10% of a project that takes a year is over a month, and with cargo that time expenditure is reduced to minutes or hours.
On the other hand, I have worked as a contractor for many years helping companies develop complex systems. It’s only a rough estimate, but I believe that I have earned over a hundred thousand dollars just by helping them with their complex build systems. A few days here, a few days there, it really adds up.
Earlier quoted context omitted.
> each clearly defined step in makefile would turn into multiple unreadable function calls in cmake Utter nonsense. For most projects CMake is far more readable and maintainable than Makefiles. There's a reason it's the only build system even close to being a de facto standard in the C++ world. And yes, CMake is totally awful. But it's still slightly better than Make. (Feel free to post the Makefile!)
> For most projects CMake is far more readable and maintainable than Makefiles That's only true for pure C/C++ projects. (I haven't used cmake with other languages so i won't comment on that.). I was specifically talking about the project where there were 7-8 shell scripts to build each intermediate step's target. When you have to call external commands to build your artifacts, you end up relying on: add_custom_targe…
Ah I assumed this was primarily a C++ project given the context of the discussion. You're right it's not really the right tool if you're not doing a C++ project!
> Example from that Makefile
Honestly that looks like a typical fragile Makefile. Grepping all over the place. Regexes. Shelling out to `dd`. This sort of build system leads to constant fighting confusing error messages. It's a "works for me" build system.
I can see one bug and it's only 10 lines!
I think you can use Makefiles robustly - if you only use it for handling the build DAG, but apparently the temptation to use it as a general scripting system is too great for basically everyone.
Earlier quoted context omitted.
I prefer the equation, :) vcpkg/NuGET + (any build system) = problem solved
Does this work across linux, mac and windows cross platform projects?
Earlier quoted context omitted.
> For most projects CMake is far more readable and maintainable than Makefiles That's only true for pure C/C++ projects. (I haven't used cmake with other languages so i won't comment on that.). I was specifically talking about the project where there were 7-8 shell scripts to build each intermediate step's target. When you have to call external commands to build your artifacts, you end up relying on: add_custom_targe…
> That's only true for pure C/C++ projects. Ah I assumed this was primarily a C++ project given the context of the discussion. You're right it's not really the right tool if you're not doing a C++ project! > Example from that Makefile Honestly that looks like a typical fragile Makefile. Grepping all over the place. Regexes. Shelling out to `dd`. This sort of build system leads to constant fighting confusing error mes…
Makefile was the only tool that felt "good enough" compared to those shell scripts. As for "works for me" problems, i directly packed up my ubuntu 14.04 rootfs for chroot and told my colleagues this was / will be the only supported build environment for this task. (docker wasn't that widespread there back then).
> I think you can use Makefiles robustly - if you only use it for handling the build DAG, but apparently the temptation to use it as a general scripting system is too great for basically everyone.
This is very true. it starts off with "Oh i can just use bash eval for this simple math" and ends with "Okay this makefile is too ugly.. might as well use a python script to handle this step". I kinda wanted to write a make tool that integrated better scripting language then. and variable checking.
Error messages were typically manageable when you sprinkle enough :"|| (echo "Error: You didn't do the right thing; exit -1)"
One of the nice things that Visual C++ has is #pragma comment(lib, "xxx.lib") You can specify it in a header file for the library. That way if you include the header file, the library mentioned will automatically get linked as long as it is somewhere in the library search path. I have found myself wishing that GCC would also get something like this.
I suspected that someone might have done it before, but didn’t know of any implementation. I’ll take a closer look at Visual C++ (used it in the last millennium for work) before deciding how mine should work.
Earlier quoted context omitted.
Every time I've tried to dabble in C++ I've had the same horrible experience. I end up "Randomly" stabbing at things until it works just well enough to get that particular thing done then dropping it all because it was such a painful experience. Compared to something like cargo which works really well, C++ and it's build tools just feel flaky. It may be that I'm just missing a mental model to get to grips with it, bu…
Same here and I am dreading starting back up again. Are there any Gradle /npm like package managers that might simplify this? Looking for something that is still alive in 2023
Conan + (any build system) = problem solved Conan has a learning curve, but it’s totally worth it. Anyone making their own build system should get some experience with a state of the art package manager before writing a single line of code, because chances are that it already solves whatever problem is motivating you.
I started as a python programmer and was very used to package managers. I believed in them, I championed them. When I switched to C++ for work I was very disheartened that there wasn't a standard. Conan obviously has promise, I haven't spent much time with it, most of my experience with C++ package managers is with nuget and vcpkg. However, my attitude toward package managers is changing. I increasingly like _not_ us…
Earlier quoted context omitted.
I started as a python programmer and was very used to package managers. I believed in them, I championed them. When I switched to C++ for work I was very disheartened that there wasn't a standard. Conan obviously has promise, I haven't spent much time with it, most of my experience with C++ package managers is with nuget and vcpkg. However, my attitude toward package managers is changing. I increasingly like _not_ us…
Yeah, this is something that bugs me about the rust ecosystem. Just to use a random number generator you need to pull in like 15 dependencies. In just a simple learning project that would have had about 1 dependency in c++, I ended up with like 75 for rust. I guess I'm old, but that seems like madness. Cargo being easy and simple is not all upside.
One of the nice things that Visual C++ has is #pragma comment(lib, "xxx.lib") You can specify it in a header file for the library. That way if you include the header file, the library mentioned will automatically get linked as long as it is somewhere in the library search path. I have found myself wishing that GCC would also get something like this.
FD: CMake developer