4 ms·

Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32

Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS, with some dependencies in nonstandard locations, etc… etc… It could. But it's an incredible coincidence that it's always cmake projects. Generally on nonstandard installs the others (e.g. scons) won't even run, so portability of the conf is not relevant.

jcelerier 6y ago
> Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS what are you talking about ? take for instance kcachegrind, it builds with cmake and works on every architecture that debian supports (https://packages.debian.org/en/sid/devel/kcachegrind https://packages.debian.org/en/sid/devel/kcachegrind). I also never had issues with x32 when I used it, nor on freebsd. Can't say for openbsd but I'd be surprised it does not work there - this seems to point that other than a minor path issue things just work: https://www.sizeofvoid.org/posts/2020-03-29-how-to-build-qt5-applications-with-cake-on-openbsd/ https://www.sizeofvoid.org/posts/2020-03-29-how-to-build-qt5....
- knorker 6y ago
  Again, project after project that doesn't work under those settings. I'm not saying CMake itself doesn't work. Though I have run into both "CMake version is too old!" and "CMake version is too new!", which by its nature can't happen with autotools.
  - rleigh 6y ago
    It can happen with the autotools. The reason it hasn't been seen recently is that there has been no significant development of note for the past 15 years. Even so, it's still common for the distributed config.sub and config.guess to be outdated. That's the price you pay for embedding stuff in each package, as opposed to requiring the build tool to be provided on the build system just like all the other tools.
    - knorker 6y ago
      > It can happen with the autotools. Yes. Again squared: project after project etcetera.

jcelerier 6y ago

> Yes, it could be that project after project after project using cmake is just "holding it wrong", and that's why it doesn't build on aarch64, openbsd, intel x32, MIPS what are you talking about ? take for instance kcachegrind, it builds with cmake and works on every architecture that debian supports (https://packages.debian.org/en/sid/devel/kcachegrind https://packages.debian.org/en/sid/devel/kcachegrind). I also never had issues with x32 when I used it, nor on freebsd. Can't say for openbsd but I'd be surprised it does not work there - this seems to point that other than a minor path issue things just work: https://www.sizeofvoid.org/posts/2020-03-29-how-to-build-qt5-applications-with-cake-on-openbsd/ https://www.sizeofvoid.org/posts/2020-03-29-how-to-build-qt5....

knorker 6y ago
Again, project after project that doesn't work under those settings. I'm not saying CMake itself doesn't work. Though I have run into both "CMake version is too old!" and "CMake version is too new!", which by its nature can't happen with autotools.
- rleigh 6y ago
  It can happen with the autotools. The reason it hasn't been seen recently is that there has been no significant development of note for the past 15 years. Even so, it's still common for the distributed config.sub and config.guess to be outdated. That's the price you pay for embedding stuff in each package, as opposed to requiring the build tool to be provided on the build system just like all the other tools.
  - knorker 6y ago
    > It can happen with the autotools. Yes. Again squared: project after project etcetera.