4 ms·

I find the build system more interesting than the "statically linked" part. Incremental compilation across your whole system is something we should have nailed

I find the build system more interesting than the "statically linked" part. Incremental compilation across your whole system is something we should have nailed by now, I think. The best I've seen is something like openembedded, where you get per-package (but not per-file) dependency tracking across the whole system. I was ever so slightly disappointed to see how manual the packaging is, with every .c file listed in each lua script. It looks quite maintenance-intensive. I was almost hoping for some kind of meta-build system which could parse automake etc. files and hoist the dependency graph into the main system build.

mforney 6y ago
> I was ever so slightly disappointed to see how manual the packaging is, with every .c file listed in each lua script. It looks quite maintenance-intensive. I was worried about this, too, but it turns out most of the cost in just the initial packaging. Packages do not tend to change their build system very much in between releases, so updating is usually just `git diff` between the version tags, sometimes adding/removing a couple source files to `gen.lua`, and regenerating `config.h`. I'm just one person, but I've been able to keep these 100 or so packages up-to-date fairly easily, while still spending most of my time developing my own projects. > I was almost hoping for some kind of meta-build system which could parse automake etc. files and hoist the dependency graph into the main system build. This would be amazing, but I think it is too difficult a problem to solve, especially with the huge variety of build systems (which are sometimes used pretty creatively). For some packages I get part of the way there with scripts or command snippets to extract source lists from the upstream build system. Here's an example: https://github.com/oasislinux/oasis/blob/master/pkg/mpv/gensources.awk https://github.com/oasislinux/oasis/blob/master/pkg/mpv/gens... One of the main motivations for the oasis build system is that it is often very difficult to get the upstream build system to do what you want. It is very common for projects to ignore your CFLAGS or LDFLAGS, ignore special include/lib directories for dependencies, or have automagic dependencies (to borrow a term from gentoo) that can't be enabled/disabled explicitly with a configure switch. Also, most build systems don't work very well for building things statically. libtool will intercept your -static flag, hiding it from the compiler, and libraries which are dependencies of other libraries get left out from the linking command.
kaba0 6y ago
Honestly, DLL hell is currently only a solved problem by nix and guix and at this point onwards, I don’t see much point in not porting everything over to the nix way of maintaining packages.

mforney 6y ago

> I was ever so slightly disappointed to see how manual the packaging is, with every .c file listed in each lua script. It looks quite maintenance-intensive. I was worried about this, too, but it turns out most of the cost in just the initial packaging. Packages do not tend to change their build system very much in between releases, so updating is usually just `git diff` between the version tags, sometimes adding/removing a couple source files to `gen.lua`, and regenerating `config.h`. I'm just one person, but I've been able to keep these 100 or so packages up-to-date fairly easily, while still spending most of my time developing my own projects. > I was almost hoping for some kind of meta-build system which could parse automake etc. files and hoist the dependency graph into the main system build. This would be amazing, but I think it is too difficult a problem to solve, especially with the huge variety of build systems (which are sometimes used pretty creatively). For some packages I get part of the way there with scripts or command snippets to extract source lists from the upstream build system. Here's an example: https://github.com/oasislinux/oasis/blob/master/pkg/mpv/gensources.awk https://github.com/oasislinux/oasis/blob/master/pkg/mpv/gens... One of the main motivations for the oasis build system is that it is often very difficult to get the upstream build system to do what you want. It is very common for projects to ignore your CFLAGS or LDFLAGS, ignore special include/lib directories for dependencies, or have automagic dependencies (to borrow a term from gentoo) that can't be enabled/disabled explicitly with a configure switch. Also, most build systems don't work very well for building things statically. libtool will intercept your -static flag, hiding it from the compiler, and libraries which are dependencies of other libraries get left out from the linking command.

kaba0 6y ago

Honestly, DLL hell is currently only a solved problem by nix and guix and at this point onwards, I don’t see much point in not porting everything over to the nix way of maintaining packages.