4 ms·

> MakeMake was designed to solve my problem (Im a C developer that develops > protable C programs using VisualStudio, and I do not want to maintain up > todate

> MakeMake was designed to solve my problem (Im a C developer that develops > protable C programs using VisualStudio, and I do not want to maintain up > todate make files for all projects and platforms). I just don't understand why you wouldn't use CMake for this? Especially since VS has built-in CMake support.

not_the_fda 3y ago
Yep, modern CMake makes this super easy, its a solved problem.
- bch 3y ago
  What constitutes “modern” here? ~15 years ago I was bitten by the CMake bug and enjoyed it for years until I got frustrated by it getting 90% of the job done and having to fight it for the last 10%. These days I have “reverted” back to BSD Make, and feel pretty good about it. So… when did CMake start its “modern” phase? Does my experience resonate with yours at all?
  - plorkyeran 3y ago
    The switch over to doing everything via target properties is the big difference between "modern" and "old school" CMake. This fixed a lot of CMake's problems other than the scripting language being awful and has mostly happened over the last decade. CMake release notes pretty consistently have at least one thing that makes me go "how is that a thing that just got implemented now and not 20 years ago?" That's not exactly a positive, but there are a very large number of things where 15 years ago you'd be shocked and frustrated to discover that there's no good way to do it, while today there's an obvious and simple way.
  - o11c 3y ago
    I stopped considering CMake when I reported a bug (that worked in all major alternatives) and they actively refused to patch it (because it was based on a traditionally-UNIX API, and they refused to use it ... even though it was available on Windows too!).
    - mathstuf 3y ago
      FD: CMake developer Do you mind pointing me to that issue? Off-HN is fine too (same GitHub handles here; grab an email address from commit metadata).
      - o11c 3y ago
        I don't remember the exact details anymore, but it related to not using `access(X_OK)` to check that a file in PATH was actually executable.
        mathstuf 3y ago
        Hmm. I see issues about finding executable-but-not-readable files, but nothing about `access(X_OK)` specifically (though GitLab's search may be failing here). Anyways, there are a number of…unfortunate behaviors that are baked in too deeply and take far longer to uproot than anyone likes. For example, the `EXISTS` predicate checked for readability…probably what was usually wanted, but sadly falls over when a broken symlink is left laying around. That one was fixed recently, but they crop up often enough. Also note that while Windows might have POSIX APIs, sometimes the semantics are just not quite right. File permissions is one such place where things "exist" but act like they're in an alternate dimension (e.g., what would `umask` do on Windows?).
tovej 3y ago
And with CMake, you also get a standard framework for testing, installing, packaging, and integrating external packages. You are shooting your future self in the foot by going out of your way to use a handbuilt new framework. It can still be valuable as a learning project.
quelsolaar 3y ago
Because Cmake requires a configuration file for each project. With makemake i can with a single command line build a new project without any configuration needed. Its one less thing to maintain.
mathstuf 3y ago
If you're never using any external dependencies, it can work. It's just the no-dep C projects are few and far between. As soon as you have things like dependencies or compiler detection, CMake or other build systems really start picking up a lot of slack. FD: CMake developer
MereInterest 3y ago
I use CMake, but can completely understand wanting to avoid it. The Makefiles that CMake produces are not at all what you want for correct reproducible builds. * Before CMake 3.20, released in 2021, CMake tracked dependencies at configuration time. As a result, any time you add/remove a header file, you need to re-run CMake in order to have correct builds. CMake 3.20 finally delegated this out to the underlying compiler. * The Makefile produced by CMake does not have a target for the object file. Even though it prints out the path `CMakeFiles/cmake_target.dir/src/my_file.cc.o`, and generates that file, you cannot run `make CMakeFiles/cmake_target.dir/src/my_file.cc.o` from inside the build directory. Instead, you need to run `make src/my_file.cc.o`, a PHONY target which actually builds the object file. * Wildcard rules in CMake are expanded to static rules in Make, rather than wildcard rules. As a result, any time you add/remove a file, such as when checking out a new branch, you need to re-run CMake in order to have a correct build. * Until recently, the makefiles produced by CMake did give useful information with `make --dry-run`. Instead of printing the command required to compile a file, it instead printed an internal delegation back to cmake. * Non-transferable build. The `CMakeCache.txt` stores a record of what options have been enabled/disabled, but also has local file information. As a result, the contents of `CMakeCache.txt` are essential to know what I actually built, but I cannot send it to somebody else as a way to reproduce my build. Makefiles generally avoid this by having explicit include files, which then can be transferred. So, in order to have correct and reproducible builds, I need to re-run CMake every time I'm building a project, the usual tools for debugging a build error are broken, and including my build environment in a bug report is useless for reproduction. I can see why somebody would want to avoid it.

not_the_fda 3y ago

Yep, modern CMake makes this super easy, its a solved problem.

bch 3y ago
What constitutes “modern” here? ~15 years ago I was bitten by the CMake bug and enjoyed it for years until I got frustrated by it getting 90% of the job done and having to fight it for the last 10%. These days I have “reverted” back to BSD Make, and feel pretty good about it. So… when did CMake start its “modern” phase? Does my experience resonate with yours at all?
- plorkyeran 3y ago
  The switch over to doing everything via target properties is the big difference between "modern" and "old school" CMake. This fixed a lot of CMake's problems other than the scripting language being awful and has mostly happened over the last decade. CMake release notes pretty consistently have at least one thing that makes me go "how is that a thing that just got implemented now and not 20 years ago?" That's not exactly a positive, but there are a very large number of things where 15 years ago you'd be shocked and frustrated to discover that there's no good way to do it, while today there's an obvious and simple way.
- o11c 3y ago
  I stopped considering CMake when I reported a bug (that worked in all major alternatives) and they actively refused to patch it (because it was based on a traditionally-UNIX API, and they refused to use it ... even though it was available on Windows too!).
  - mathstuf 3y ago
    FD: CMake developer Do you mind pointing me to that issue? Off-HN is fine too (same GitHub handles here; grab an email address from commit metadata).
    - o11c 3y ago
      I don't remember the exact details anymore, but it related to not using `access(X_OK)` to check that a file in PATH was actually executable.
      - mathstuf 3y ago
        Hmm. I see issues about finding executable-but-not-readable files, but nothing about `access(X_OK)` specifically (though GitLab's search may be failing here). Anyways, there are a number of…unfortunate behaviors that are baked in too deeply and take far longer to uproot than anyone likes. For example, the `EXISTS` predicate checked for readability…probably what was usually wanted, but sadly falls over when a broken symlink is left laying around. That one was fixed recently, but they crop up often enough. Also note that while Windows might have POSIX APIs, sometimes the semantics are just not quite right. File permissions is one such place where things "exist" but act like they're in an alternate dimension (e.g., what would `umask` do on Windows?).

tovej 3y ago

And with CMake, you also get a standard framework for testing, installing, packaging, and integrating external packages. You are shooting your future self in the foot by going out of your way to use a handbuilt new framework. It can still be valuable as a learning project.

quelsolaar 3y ago

Because Cmake requires a configuration file for each project. With makemake i can with a single command line build a new project without any configuration needed. Its one less thing to maintain.

mathstuf 3y ago

If you're never using any external dependencies, it can work. It's just the no-dep C projects are few and far between. As soon as you have things like dependencies or compiler detection, CMake or other build systems really start picking up a lot of slack. FD: CMake developer

MereInterest 3y ago

I use CMake, but can completely understand wanting to avoid it. The Makefiles that CMake produces are not at all what you want for correct reproducible builds. * Before CMake 3.20, released in 2021, CMake tracked dependencies at configuration time. As a result, any time you add/remove a header file, you need to re-run CMake in order to have correct builds. CMake 3.20 finally delegated this out to the underlying compiler. * The Makefile produced by CMake does not have a target for the object file. Even though it prints out the path `CMakeFiles/cmake_target.dir/src/my_file.cc.o`, and generates that file, you cannot run `make CMakeFiles/cmake_target.dir/src/my_file.cc.o` from inside the build directory. Instead, you need to run `make src/my_file.cc.o`, a PHONY target which actually builds the object file. * Wildcard rules in CMake are expanded to static rules in Make, rather than wildcard rules. As a result, any time you add/remove a file, such as when checking out a new branch, you need to re-run CMake in order to have a correct build. * Until recently, the makefiles produced by CMake did give useful information with `make --dry-run`. Instead of printing the command required to compile a file, it instead printed an internal delegation back to cmake. * Non-transferable build. The `CMakeCache.txt` stores a record of what options have been enabled/disabled, but also has local file information. As a result, the contents of `CMakeCache.txt` are essential to know what I actually built, but I cannot send it to somebody else as a way to reproduce my build. Makefiles generally avoid this by having explicit include files, which then can be transferred. So, in order to have correct and reproducible builds, I need to re-run CMake every time I'm building a project, the usual tools for debugging a build error are broken, and including my build environment in a bug report is useless for reproduction. I can see why somebody would want to avoid it.