Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Remove Makefile build, exclusively use CMake #86

Open
3 tasks
erichte-ibm opened this issue Feb 6, 2024 · 0 comments
Open
3 tasks

Proposal: Remove Makefile build, exclusively use CMake #86

erichte-ibm opened this issue Feb 6, 2024 · 0 comments
Milestone

Comments

@erichte-ibm
Copy link
Collaborator

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.
@erichte-ibm erichte-ibm added this to the 1.0.1 milestone Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant