4 ms·

Sadly, the POSIX specification for "make" is notoriously limited. They only spec'ed what everyone could agree on, and that wasn't much. I'm sure there are cases

Sadly, the POSIX specification for "make" is notoriously limited. They only spec'ed what everyone could agree on, and that wasn't much. I'm sure there are cases where a make that only implements the POSIX spec is fine.. and if this is useful, great!! However, many projects that use "make" will outgrow it. I think many people just assume GNU make when they use a make; GNU make has lots of additional capabilities that turn out to be useful, and it runs practically everywhere. Your mileage may vary.

ori_b 4y ago
> Extensions from a future POSIX standard have been added. Note that these are subject to change until the standard is finally published. The extensions listed cover most of what I'm currently missing from posix make.
hvdijk 4y ago
Even for those that do not assume GNU make, this may not be enough. GNU Autotools are not limited to running on GNU make, but this make does not implement everything used by Autotools. The first thing I noticed it does not handle is VPATH (https://www.gnu.org/software/make/manual/html_node/General-Search.html https://www.gnu.org/software/make/manual/html_node/General-S...) which is used by Autotools for out-of-tree builds (mkdir build && cd build && ../configure && make as opposed to ./configure && make).
- zxwrt 4y ago
  But out-of-tree builds feature is optional, right?
  - hvdijk 4y ago
    It depends on the package. As far as Autotools itself are concerned, yes, users are free to choose whether to do in-tree or out-of-tree builds, but some packages require one or the other.
chubot 4y ago
Yeah I'm left scratching my head at the purpose of this project. I wrote 3 GNU makefiles from scratch (a few hundred lines each) starting in ~2016 for https://www.oilshell.org/ https://www.oilshell.org/, and regret it. I switched to Python + Ninja, and I should have just used that all along. So I think GNU make is already pretty old and regretted, and POSIX make even more so. CMake + Ninja seems be pretty common these days, but for my project Python works fine, and is a lot simpler. CMake is also a bad (shell-like) language, but I'm pretty sure it's better and more featureful than GNU make (i.e. you're less likely to need to switch build systems/languages due to a new requirement) This thread has some interesting experiences ... it does seem like there needs to be a better high level language to generate Ninja https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc Also, for portability I just generate a shell script instead of Ninja (even though Ninja is extremely portable and has multiple implementations now). For tarball distributions you probably don't need incremental builds. All the user should need to compile software is a shell, not ANY make!
- frankohn 4y ago
  My experience aligns well with your. For any moderately complex project makefiles are inadequate and trying to make them work is a frustrating experience even in GNU make is pretty capable. Ninja is a fine tool but it requires an higher level language to generate it's build files. Cmake is just horrible, I just cannot stand it. I choose Meson instead and I am quite happy with it. Meson developers focus a lot on doing the right design decisions. They keep the language very simple and offer mostly one logical way to do a thing and Meson ensure it works right in every circumstance. Yet it offers advanced options when they are required but they are always well thought out. If you compare meson to make at first you may think make is more flexible but ultimately it leaves to you many problems it doesn't solve and it turns out to be inadequate. With make, declare automatically dependencies from header files? You are alone, that's your problem. There are some tricks using GCC but they looks like hacks. Maintain projects build logic across subfolders? That's your problem. Make only provide a very rough, inadequate mechanism. Want to do parallel build by respecting dependencies across folder? Sorry, that's your problem but it may work using some tricks. Want to build out of tree? Hmmm not supported in a standard idiomatic way. You need to use tricks. How you create a static library in a cross-platform way? That's your problem. The same for shared libraries. Personally I think that make is an obsolete tool whose design is inadequate very much like CVS that was replaced by git. To me the only downside of Meson is that it requires python but I can accommodate with that.

ori_b 4y ago

> Extensions from a future POSIX standard have been added. Note that these are subject to change until the standard is finally published. The extensions listed cover most of what I'm currently missing from posix make.

hvdijk 4y ago

Even for those that do not assume GNU make, this may not be enough. GNU Autotools are not limited to running on GNU make, but this make does not implement everything used by Autotools. The first thing I noticed it does not handle is VPATH (https://www.gnu.org/software/make/manual/html_node/General-Search.html https://www.gnu.org/software/make/manual/html_node/General-S...) which is used by Autotools for out-of-tree builds (mkdir build && cd build && ../configure && make as opposed to ./configure && make).

zxwrt 4y ago
But out-of-tree builds feature is optional, right?
- hvdijk 4y ago
  It depends on the package. As far as Autotools itself are concerned, yes, users are free to choose whether to do in-tree or out-of-tree builds, but some packages require one or the other.

chubot 4y ago

Yeah I'm left scratching my head at the purpose of this project. I wrote 3 GNU makefiles from scratch (a few hundred lines each) starting in ~2016 for https://www.oilshell.org/ https://www.oilshell.org/, and regret it. I switched to Python + Ninja, and I should have just used that all along. So I think GNU make is already pretty old and regretted, and POSIX make even more so. CMake + Ninja seems be pretty common these days, but for my project Python works fine, and is a lot simpler. CMake is also a bad (shell-like) language, but I'm pretty sure it's better and more featureful than GNU make (i.e. you're less likely to need to switch build systems/languages due to a new requirement) This thread has some interesting experiences ... it does seem like there needs to be a better high level language to generate Ninja https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc Also, for portability I just generate a shell script instead of Ninja (even though Ninja is extremely portable and has multiple implementations now). For tarball distributions you probably don't need incremental builds. All the user should need to compile software is a shell, not ANY make!

frankohn 4y ago
My experience aligns well with your. For any moderately complex project makefiles are inadequate and trying to make them work is a frustrating experience even in GNU make is pretty capable. Ninja is a fine tool but it requires an higher level language to generate it's build files. Cmake is just horrible, I just cannot stand it. I choose Meson instead and I am quite happy with it. Meson developers focus a lot on doing the right design decisions. They keep the language very simple and offer mostly one logical way to do a thing and Meson ensure it works right in every circumstance. Yet it offers advanced options when they are required but they are always well thought out. If you compare meson to make at first you may think make is more flexible but ultimately it leaves to you many problems it doesn't solve and it turns out to be inadequate. With make, declare automatically dependencies from header files? You are alone, that's your problem. There are some tricks using GCC but they looks like hacks. Maintain projects build logic across subfolders? That's your problem. Make only provide a very rough, inadequate mechanism. Want to do parallel build by respecting dependencies across folder? Sorry, that's your problem but it may work using some tricks. Want to build out of tree? Hmmm not supported in a standard idiomatic way. You need to use tricks. How you create a static library in a cross-platform way? That's your problem. The same for shared libraries. Personally I think that make is an obsolete tool whose design is inadequate very much like CVS that was replaced by git. To me the only downside of Meson is that it requires python but I can accommodate with that.