cmake and *.cmake files are missing from docker containers

[devkitpro]

cmake and *.cmake files are missing from docker containers

[WinterMute]

Of about 15 homebrew apps I have come across, only four used make. All others used cmake.

And, of the 100s of homebrew apps I've encountered, a mere handful use cmake.

Regardless of personal opinions of which is the better build system*, cmake is used rather often nowadays, see e.g. the portlibs. Nice features of it are out of source builds, a GUI, and abstracting away from calling some kludged together sequence of random shell commands directly which entangle the build system with the local state, e.g. shell version, ENV vars etc.

Most of the portlibs use autotools. Most of what you're saying here just tells me that you have little experience with autotools and you don't like it.

By explicitly not supporting cmake, the number of wrong cmake solutions will only go up. There are already 5 or so different broken cmake toolchain files on Github simply because users were not aware that devkitpro does have a toolchain file (it is hidden in the portlibs support tools).

Or perhaps because they don't know the templates exist or how to use them.

*Rant: I think cmake is only as bad at cross-compiling as the toolchain file is. If a good toolchain file is provided, the cross compilation should just work by using -DCMAKE_TOOLCHAIN_FILE=....

In my experience cmake is a nightmare for cross-compiling. There's way more to getting it to behave than just a toolchain file - you need to bear in mind that we're not running a conventional OS here and 90% of how easy it is to compile random libraries with devkitA64 is the work we put into our posix compatibility layer.

Concerning make+configure+autotools, where shall I start? Relying on env vars to configure the build? Relying on in-source building cluttering up sources with objects? Or the unmaintainable garbage fire that is autotools, configure scripts trying to "guess" the host system properties to overcome shortcomings of make. Sometimes these are written in bash, sometimes in python, there's no standard, just some shell script called configure. Then there are higher order meta-systems that generate configure scripts that themselves generate makefiles. It is just terrible bloat with way too much state everywhere. So, yes after writing this, I find that maybe a bit more horrific than cmake's approach to fix some of these problems.

proper configure scripts are never written in python, it's not just "some shell script called configure" there very definitely is a standard. configure scripts are generated from a template using autoconf - see https://github.com/devkitPro/tex3ds/blob/master/configure.ac for example.

This is becoming majorly unproductive though, I don't really want to debate the merits of any particular build system over any other. The fact remains that we're currently using autotools, cmake, meson and "plain" Makefiles in a variety of places depending on requirements. We produced a standard Makefile which we're using with various tweaks for all the consoles we support so novices don't have to get involved in this endless quagmire. It works everywhere, nobody needs to care what OS they're running or what direction slashes are.

The reason I wanted to get you on IRC to chat about this stuff was to find out what you're building and why you think cmake is the best way to do it. There seems to be a bit of a cmake fetish going on in Vita homebrew land & I've noticed some switch ports being ported from Vita ports rather than from the original code - in some cases with upstream projects that use autotools & not cmake. It's all a bit concerning and interferes with the direction I've taken with devkitPro.

[glebm]

I'm working on DevilutionX and the project uses CMake (including cross-compilation for many platforms). I wanted to run this Docker container on CircleCI.

Working around the issue was quite simple:

dkp-pacman -S --needed --noconfirm --quiet devkitpro-pkgbuild-helpers

Writing the correct CMake files was not simple (as the devkitpro-pkgbuild-helpers CMake toolchain files are missing some things) but doable.

[WinterMute]

Most homebrew apps use make and we don't encourage use of cmake - it still has horrific problems cross compiling as well as creating support issues for us when toolchain users get in a mess trying to sort it out.

The toolchain files are intended for use with portlibs that only have cmake based build systems available and aren't really suitable for general use at this time.

[rsn8887]

Of about 15 homebrew apps I have come across, only four used make. All others used cmake.

Regardless of personal opinions of which is the better build system*, cmake is used rather often nowadays, see e.g. the portlibs. Nice features of it are out of source builds, a GUI, and abstracting away from calling some kludged together sequence of random shell commands directly which entangle the build system with the local state, e.g. shell version, ENV vars etc.

By explicitly not supporting cmake, the number of wrong cmake solutions will only go up. There are already 5 or so different broken cmake toolchain files on Github simply because users were not aware that devkitpro does have a toolchain file (it is hidden in the portlibs support tools).

*Rant: I think cmake is only as bad at cross-compiling as the toolchain file is. If a good toolchain file is provided, the cross compilation should just work by using -DCMAKE_TOOLCHAIN_FILE=....

I personally hate both make and cmake, for different reasons.

I hate cmake for it's horrible syntax, way too many pre-defined ALL_UPPERCASE variables and impossibility to find out what's happening under the hood for debugging.

Concerning make+configure+autotools, where shall I start? Relying on env vars to configure the build? Relying on in-source building cluttering up sources with objects? Or the unmaintainable garbage fire that is autotools, configure scripts trying to "guess" the host system properties to overcome shortcomings of make. Sometimes these are written in bash, sometimes in python, there's no standard, just some shell script called configure. Then there are higher order meta-systems that generate configure scripts that themselves generate makefiles. It is just terrible bloat with way too much state everywhere. So, yes after writing this, I find that maybe a bit more horrific than cmake's approach to fix some of these problems.

[fincs]

Of about 15 homebrew apps I have come across, only four used make. All others used cmake.

I don't see how this statement can be true. The examples all use devkitPro-style makefiles. Native projects (i.e. non-ports) all use devkitPro-style makefiles.

out of source builds

Anyone who claims you can't do out-of-source builds with autotools is lying.

abstracting away from calling some kludged together sequence of random shell commands directly which entangle the build system with the local state, e.g. shell version, ENV vars etc.

None of this is true for devkitPro-style makefiles, which is the primary build system we support and recommend for native projects.

By explicitly not supporting cmake, the number of wrong cmake solutions will only go up.

By explicitly supporting cmake, the number of cmake-using projects will only go up. We do not want the number of projects using cmake to go up.

Relying on env vars to configure the build?

Not relying on env vars to configure the build is a dumpster fire that makes cross compilation with devkitPro toolchains a horrible mess.

In our experience, cross-building portlibs using autotools takes several orders of magnitude less effort than building cmake-based portlibs.

[rsn8887]

I was talking about ports of course, not the one or two pong and snake games that are native projects.

My reason of arguing for cmake support is not for new projects but for ports.

I honestly don’t understand the supposed benefit of env vars which are not grouped, e.g. where it is hard to disentangle the host from target config, compared to a single toolchain file per possible target where everything that’s relevant for cross compilation is already grouped together and defined in a host independent way.

Example: backslash vs slash on Linux and Windows, completely messes up autotools, but not cmake.

[rsn8887]

Ok fine with me. I don't really have a problem building anything right now. Both cmake and autotools work with the toolchain. It was just a bit of a journey to get there for me. I thought others could maybe be spared. But then, all they have to do is just look at build instructions from recent Switch releases here on GitHub if they are really interested. So I guess that's ok then.

[WinterMute]

It's not OK if people are being encouraged to use cmake in preference to existing build frameworks though. cmake isn't installed by default on any OS and many of the build instructions for various projects I see involve modifying the toolchain in ways that will break.

[glebm]

@WinterMute Dave, why did you edit out the last part of my comment? Do you have a better example of using CMake for this?

[fincs]

We do not support using cmake for building anything other than cross compiled portlibs. We especially do not want to see people use or promote cmake and cmake-using 3rd party project templates. Users should stick to the devkitPro makefile based templates we provide along with the examples for each platform.