Versions Compared

Old Version 1

changes.mady.by.user Tomasz Cedro

Saved on

compared with

New Version Current

changes.mady.by.user Tomasz Cedro

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Overview

Info

Note: The decision to switch from GNU Make to CMake is highly controversial. Many people are wildly in favor and a large number are strong opposed. This is a change that must be brought before the PMC for a vote before any action is taken.

  • There is an idea to add CMake build system.. that would probably at some point replace current GNU Make.
  • There are strong supporters of GNU and C Make in the community, but also people with neutral position unless new solution is proven better in practice.
  • Current approach is to create Proof-of-Concept CMake build configuration right next to existing GNU Make infrastructure, so process is non-invasive and can provide desired metrics that will prove new solution better or worse.
  • Because this RFC will have huge impact on the project, a list of detailed Pros and Cons with measurable metrics needs to be created in order to provide good analysis that will feed the approval by voting process. The list of pros and cons and impact is presented below on this page.
  • Special rules apply to code change votes.  We don't often do votes on code changes.  But such votes are critical in order to serve the community with fairness.

  • We need to get away from statements of fears and marketing statements to understand the clear, real world impacts.

  • Related PR:

CMake vs GNU Make IMPACT

  1. Introduces additional build dependency (with frequent updates) to the project.
    1. Self-compatibility and enforced-changes risks with frequent updates while GNU Make is already rock solid stable.
  2. Two alternate overlapping build systems:
    1. Heavy initial burden of work.
    2. Doubled effort in maintaining two parallel build systems.
    3. High risk of Inconsistencies and self-incompatibilities in transition period.
  3. CI and Build automation tools must be re-written from scratch everywhere:
    1. NuttX project internals.
    2. users.
    3. customers.
    4. companies.
    5. documentation.

CMake vs GNU Make PROS (in favor)

  1. Better Integration with modern Continuous Integration automation and build systems:
    1. Better CI maintenance with cmake.
      1. CI admin needs to use "hacks" to operate GitHub CI with GNU Make.
      2. cmake is better aligned with GitHub CI framework.
    2. Improved PR processing:
      1. Reliable automated testing of each provided PR on GitHub when using cmake.
    3. Improved Build Efficiency:
      1. Build times better with CMake than GNU Make.
        1. TODO: We need a proof for that, some sort of comparison table + chart with real world data.
    4. Allows building various configurations in sub-directory of a single source tree.
      1. shorter fetch related time.
      2. leverages parallelism for several builds at the same time.
  2. Clean code:
    1. Everything is way more readable then the current Make files.

    2. Easier on-boarding.

      1. new users may be more familiar with CMake.
      2. easier initial configuration process.

    3. Less build-related bugs.

      1. TODO: explanation needed.

    4. Less boiler-plate code.

      1. TODO: explanation needed.
  3. Better efficiency:
    1. people often refer that CMake build is faster than GNU Make:
      1. TODO: Provide real world in-NuttX measurements comparison.
    2. CMake can generate build configuration files for various build mechanisms (i.e. GNU Make, ninja, etc).
  4. Great Integration with modern IDE:
    1. TODO: details required here.
  5. Good well proven portability.
  6. Can act initially as separate build system aside and with no conflict to current GNU Make.
  7. "Modern".
    1. TODO: details required here.

CMake vs GNU Make CONS (against)

  1. CMake is less flexible than GNU Make.
  2. GNU Make is small and efficient (i.e. builds firmware in ~20 seconds). "If it is not broken, don't fix".
  3. Introduces additional build dependency to the project.
  4. Self-compatibility and enforced-changes risks with frequent updates while GNU Make is already rock solid stable.
  5. Two alternate overlapping build systems:
    1. Heavy initial burden of work.
    2. Doubled effort in maintaining two parallel build systems.
    3. High risk of Inconsistencies and self-incompatibilities in transition period.
  6. Additional work:
    1. CI and Build automation tools must be re-written from scratch everywhere:
      1. project itself.
      2. users.
      3. customers.
      4. companies.
      5. documentation.

References

  1. https://cmake.org/overview/
  2. https://www.gnu.org/software/make/
  3. Trilinos CMake Evaluation (https://www.sandia.gov/app/uploads/sites/143/2021/10/daniel-dunlavy-2008-SAND2008-7593.pdf).

  4. A Build System for Benchmarking and Comparison of Competing System Implementations, Anthony J. Bentley, University of New Mexico (https://digitalrepository.unm.edu/ece_etds/298/).

  5. https://earthly.dev/blog/cmake-vs-make-diff/
  6. https://www.g2.com/compare/cmake-vs-gnu-make
  7. https://www.incredibuild.com/blog/cmake-vs-make