seL4
seL4 copied to clipboard
seL4
Use CMake file(SIZE ...) instead of stat
Follow-up from https://github.com/seL4/seL4/pull/826
Avoid the stat utility altogether, by using the built-in file (SIZE ...) command that became available in CMake version 3.14.
The point in #826 was not to do that yet, because we don't want to require CMake 3.14. We should revisit this in a year or two.
Ubuntu 20.4/LTS has CMake 3.16, see https://packages.ubuntu.com/focal/cmake Debian Bullseye has CMake 3.18, see https://packages.debian.org/bullseye/cmake Ubuntu 22.4/LTS will have CMake 3.22, see https://packages.ubuntu.com/jammy/cmake
Given that a switch from Ubuntu 18.4 to 20.4 is planned anyway, this seems the only practical blocker.
I don't think we're planning to give up support for 18.04, we're just switching the default to 20.04 because it's more common (although 22 is coming out, so maybe that should be the target instead, there hasn't been any discussion about this yet that I'm aware of).
End of life for Ubuntu 18.04 is Apr 2023, so that would be a good time to drop support for older tool chains, I think.
I don't know how much it matters for seL4 proper, but it looks like ubuntu 22 is the first one above that has > cmake 3.19, which added cmake builtin support for json. It could perhaps be nice if some things were driven by JSON like lists of architectures.
The cmake <-> cargo integration recently gained support for this, so on such versions it no longer requires preinstalled host tools, as cmake can just directly communicate with cargo via json.
So thats a :+1: from me if you want to make the leap to 22.
In CMake 3.17 CMAKE_CURRENT_FUNCTION_LIST_DIR was added, which comes handy in some cases also.
So, this is complicated. The user experience of getting the right build toolchain installed is already pretty complex. If we add to that a step to manually upgrade cmake, I don't think that is a good idea. We might do that for Ubuntu 18.04 in 2023, but Ubuntu 20.04 is going to be around and extremely common for quite a while, as will be Debian Bullseye, so going beyond cmake 3.16 will make things harder for a whole lot of people.
To upgrade manually, you roughly have to
- uninstall current version
- either download and compile from source or
- add kitware apt repo, install their keys, and install from there
It's not impossible, but I can see it going wrong plenty.
Since the only thing we really need from cmake 3.19 is fairly simple json output (one big list) -- would it be possible to implement that functionality as a cmake function we define ourselves? We could then drop that function later when 3.19 as default is widespread.
FWIW, I am fine with waiting,
In my cmake scripts for rust support where I link in corrosion via repo.
This currently requires additional installation steps install corrosion, ensure cmake environment variables can find it.
Eventually that will go away or can be bypassed perhaps by using cmake 3.19+, where cmake can parse cargo metadata directly.
For the kind of JSON like architecture lists provided by seL4, since seL4 depends on python already it is a bit easier to do something like shell out to a python script for parsing seL4 provided JSON. It seems to be more of an issue when reusing external cmake scripts which don't necessarily depend upon python.
It definitely sounds like waiting to bump to 3.19 is the prudent option. It isn't really blocking anything for me it just just a bit awkward to have additional installation steps above and beyond those required for building seL4 proper.
From the comments it seems using docker is still not considered the way to go? Because that solves the whole issue nicely to have arbitrary build environments in parallel and also have a recipe to follow in case one needs to adapt it. The container can also be made a VM - but there it might get a bit inconvenient already.
Docker is only provided as a convenience, not as the one and only way to build seL4, and I don't think we should go there, that would be way too limiting.
From a personal experience perspective, I've been using docker for a while for Mac builds and I can't say I enjoy the experience compared to having the tool chain working natively. It is more deterministic and helps debugging potential tool chain issues, but that's about it.
Are we going to do anything with this? In my opinion there does not seem to be any issues with compiling seL4 on Linux or macOS and so using CMakes builtin functionality instead of stat will not yield any benefits.
You're right. I'm closing this issue specifically for stat. I'd say json export is a separate issue we should think about, and we could re-open or create one for that when standard cmake versions are close enough for this to be a topic again.