You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The primary motivation for this is to no longer maintain two build systems, that currently do not have the same feature set. I propose that we improve the CMake build to match the functionality of the Makefile build, then remove the Makefile build.
Off the top of my head, this would require:
Running unit test cases
Ensure debug/release builds are correctly split (potentially have ASAN as an independent option, enabled by default for tests?)
Static analysis shortcuts like make cppcheck, make format.
Here is a probably non-exhaustive opinionated list of the pros and cons of each build system, subject to change:
CMake
Pros
Very easy to integrate into rpmbuild workflows, probably other packagers as well
Fairly easy to add options and other targets, without needing to write a bunch of boilerplate logic
Largely takes care of a lot of compiler flags, dependency linking, etc
Plenty of documentation, and is a fairly standard choice in the ecosystem*
Unlikely to cause issues when building from a weird environment
See con in Makefile, for more clarity
IDEs/etc probably have better tooling/integration
= Makefiles are standard, but there is no standard for custom Makefile build systems, and can lead to a lot of jank. Autotools and CMake avoid a lot of the jank of custom Makefiles.
Cons
Somewhat arcane to initially set up
More difficult to implement or run simple shortcuts like cppcheck or format
Note: these could be served by a script instead that runs all the static analysis and/or
Requires slightly more effort to run a build (make vs cmake --build foo)
Makefile
Pros
Quicker to use (just type make)
Much easier to integrate shortcuts like make format
Low level control over the build -- easier access to compiler flags, linking, custom intermediate steps, etc
Does not depend on an additional build tool (make is ubiquitous)
Cons
Everything has to be written from scratch, much more error-prone
Integration and building from other directories has to be handled manually and carefully
To clarify, running make clean as root (stupid, I'm aware. Container problem.) deleted my /bin and /lib directories because some variable wasn't set correctly, therefore appending /bin to "" results in /bin.
Harder to get contributions for, as it would require someone to understand your Makefile system
No default integrations with packaging, will have to manually handle install/uninstall targets
Heavy opinion here: documentation is acceptable, but unclear on some harder-to-grasp concepts that higher level build systems handle for you.
Anything with wildcards can be a massive pain if not done in a particularly idiomatic way, but there is no document that I've found that defines good idioms.
The text was updated successfully, but these errors were encountered:
The primary motivation for this is to no longer maintain two build systems, that currently do not have the same feature set. I propose that we improve the CMake build to match the functionality of the Makefile build, then remove the Makefile build.
Off the top of my head, this would require:
make cppcheck
,make format
.Here is a probably non-exhaustive opinionated list of the pros and cons of each build system, subject to change:
CMake
Pros
Cons
cppcheck
orformat
make
vscmake --build foo
)Makefile
Pros
make
)make format
make
is ubiquitous)Cons
make clean
as root (stupid, I'm aware. Container problem.) deleted my/bin
and/lib
directories because some variable wasn't set correctly, therefore appending/bin
to""
results in/bin
.The text was updated successfully, but these errors were encountered: