Replacing the build system with cmake or gn

[mcr]

@maribu

Let’s call the set of all currently generated build dirs a cache. A cache entry would be one build dir. Whenever configurations are changed upstream (e.g. renaming a module) a subset of the cache entries would become invalid.

As a user, I can live with having to change my Makefile if a module gets renamed. I hope that my list of makefile (or whatever we use, if it’s not make) includes is abstract enough that this doesn’t happen that often.

The list of things that the CI needs to validate (the prebuilt caches) could be annoying to maintain. But if a module is renamed and the CI isn’t updated, then the CI will fail, and stuff will get fixed, right?

@maribu

Whenever new modules or boards are added, the cache needs to grow. I don’t think it is trivial to keep the cache in sync with the upstream source, but this is what we need for the CI.

I agree that trade-offs where trading in UX for better CI integration are hard to swallow. But first, I don’t think there are too many trade-offs to be made, since the goals both have are quite often well aligned (e.g. simplicity, ease of maintenance, well structured, and so on will be nice for both). And second, the CI prevents a lot of bugs from slipping through. And bugs are really bad for UX.

I think we are in violent agreement. I’m not arguing against CI. Just opposite. What I’m arguing against is CI systems that take over and dominate the system such that they are no longer useable documentation for end users. I’ve seen a number of projects that have gone that way, or seem to: Yocto, buildbot. I would like to put openwrt on that list, but actually, I find it’s gone to a place where it’s helping neither end users nor CI