I thought this was a pretty useful project for embedded work, and despite it being a few years old I'd never heard of it.
The documentation is a bit... eclectic.
Tup is a build system that keeps track of what files a command accesses. So if you run make from tup, it can look at every file your makefile reads from, and re-run make if any of those files change. Not that useful, in that example, but when you have it run gcc to make each source file instead, it can automatically rebuild just the files that need to be rebuilt.
Building on top of that, they've set up a git repo with the appropriate "tupfiles" (makefiles) to build linux and enough userspace to get by. It's not so much a linux distribution as a build-system that can build an entire linux distro from source.
The big difference between this and a normal build system is that all your source files can be in the same tree as git submodules, and `tup upd` will rebuild the entire thing, only recompiling code who's source file or shared libraries have changed.
I think it could be a pretty powerful system for a lot of projects, I'm particularly interested in using it for building android images, and firmware for ereaders.
I wouldn't say a Linux distro package system is largely defined by how software is built form source, but it can be, and it at least matters in all cases.
I would say the package dependency tree is probably the most important, defining feature of the package system. Second to that is delivery (and the fact it's so high on the list is a testament to its importance, as I can remember a time before it when we just had RPM and dpkg). Some package managers also build form source, but that's a quirk of hose those operate, not really a core requirement to delivering binaries to the end user.
Even FreeBSD's ports build system is largely defined be its dependency tree and the rules they have in place to make fetching and building easy. Whether binaries are delivered from it or source that's compiled locally is somewhat transparent to the end user, other than the extra time it takes.
I think GP was saying that even the Linux package managers that deliver binaries tend to build their own packages with a distro-specific build system rather than just repackaging upstream binaries
Ah, yes. It's entirely possibly I missed the point. :)
Although repackaging upstream can be a fuzzy concept. E.g. Ubuntu's early days. They've always repackaged Debian packages, but I believe there was less differentiation in the beginning, before Ubuntu has many of its own initiatives and projects.
The big difference being that in order to get any real benefit you can't use upstream's build system, you need to use tup. I'd say it's not a linux distro yet.
I would say that’s definitely a huge benefit to the end users (though not the maintainers, that’s for sure) as “one build system to rule them all” is pretty much the dream, right?
Presuming tup is good, of course. I played with it but I hated the fuse dependency and ended up switching to meson (though I despise the build-time python dependency, see [0]) for cross-platform projects and plain jane gmake or pmake Makefiles for others. I also hand code ninja build files for stuff that’s not too crazy and platform dependent, basically for things that gulp would normally be in control of.
I really wanted to like tup, but I feel like it's just missing to many 'basic' things, along with being a bit annoying to setup and use. The big thing for me is that there is no `tup clean`, and also no way to create phony targets or multiple targets like with `make` - and they're not excluded because of complexity reasons, but because they just don't think it should be the job of the build system [0]. Which, they might be right, but if I can't actually replace my full Makefile's with Tupfiles, but instead have to replace it with Tupfiles + Makefile/shellscripts/installscripts/etc. then Tup is a lot less appealing to me. This is especially an issue since the scripts have no way of accessing the Tup information.
With that said, I was curious how this project got around the 'install' problem, but it seems like they were largely able to just side-step the issue. They build an `initrd` from tup, and the `initrd` Tupfile copies all of the compiled executables into their proper folders before generating the `initrd`. So the projects themselves can't install themselves directly onto a system.
I agree with you, it's not there yet. It's the same problem over and over again with all these Make alternatives: close but if only xxx or if only not yyy.
I agree that the installation approach is a total copout, I would have hardlinked all the files from their installation destination to the build artifacts. (presuming state is intended to be thrown away on rebuild.)
I think what bugs me the most is that `tup` has been around for years now (The v0.1 release was in 2009), and it is almost exactly what I want - it keeps a very similar setup to `make`, but much better support for the stuff `make` makes a bit painful to do. If it had support for `tup clean` and for defining phony targets like `install` I would likely be using Tupfiles for all of my projects.
It's extremely unlikely that Tup provides a "clean" command. They've expressed a philosophical opposition to it on a few occasions: https://github.com/gittup/tup/issues/120
They're make a really clear distinction between a build system, and a build support system. The "clean" command falls into build support, and the Tup team would argue this is better served with techniques like "git clean -xdf"
The "make clean" command is not perfect. Even if someone writes this make phase correctly, it may break after you sync new makefile changes on a dirty project dir. What do you do in that case?
I understand it's not going to happen - I linked one such conversation in my first comment. I think the reasoning is silly (His definitions might be "right", but he's the only one using those definitions), but I'm not arguing with them about it.
And I agree that `make clean` isn't perfect, I think that is what makes the fact that `tup clean` doesn't exist even more annoying. A lot of people recommend including an auxiliary Makefile or script to do the cleaning, but it can never be as good as if `tup` just did it itself since it is aware of exactly what files it as created during the build process.
so silly this isn't included because of philosophical objections.
tup is in some ways brilliant, and i give it kudos for actually improving on make in many ways (unlike 99% of the make-replacement-hopefuls), but man oh man do i value and prefer software devs with a more user-focused philosophy.
(an excellent example of that would be homebrew, which arguably wasn't anything special from a pure-tech perspective, but had amazingly good product sense/user focus. imagine combining that attitude & ux skills w/ the technical brilliance of tup...)
For what use case do you need to perform a 'clean'?
Every time I have needed to clean a Makefile based project it has been due to imperfections of the build system, i.e. needing to do a full rebuild. In theory (I've never used tup in anger) you should never need to do that with tup because the dependecy gathering is so robust.
maybe you want to time a rebuild, maybe somehow something outside of tup's knowledge changed, maybe you want to tar the directory w/o build artifacts, maybe you simply need to quickly free up some hd space, &c &c
This is interesting. I have been wondering about the viability and communuty interest in a service to enable subscription service for CI/CD systems at the project level.
OSS maintainers don't have a unified mechanism to alert packagers of updates.
In place of a dirty hack to power IFTTT and Jenkins from fetchmail scripts when there is an announcement, we could have intelligence and transparent automation at the distro-level.
Maintainer patches a 0-day, and there's a mad scramble for everyone to patch, test, package and publish.
I would rather not wait on Debian to release a distribution or be forced to cherry-pick from Sid.
OpenSolaris and OpenBSD could have feature parity with Cygwin and Alpine.
We could have concurrent versioning, automation and container and filesystem-based deployments become a little less risky.
Debian has vcswatch to keep track of updates. I think it only works if the upstream repository keeps the Debian control files updated, but keeping track of commits that update a generic CHANGELOG file should be simple.
That said, I don't think the vendor can be avoided unless you want to live on the edge. If you're on a released version of a distro (otherwise, you wouldn't have to cherry-pick from Sid), chances are you're not on the latest version of the software, and the patch has to be backported by the distro maintainer to version you are actually on.
I'll admit it started skeptical based on the headline, but reading the page, I changed my mind, this seems like something worth at least trying to see what package management feels like. It'd be pretty cool if something like this could help smooth out package version incompatibilities.
In particular this idea is intriguing (and the honesty about not having tried it is appreciated):
> Bisection!
> Let's say your compy86 is running fine, and then you update to get the latest, and something breaks. You can use git bisect across your entire linux distribution to find the commit that broke it.
> Note: It may not work across config changes, since tup doesn't automatically run 'oldconfig' when necessary.
> Note: I've never actually tried this, so we'll just assume it works.
I agree. Usually names in format XY where X is a trademark are considered infringing. See several cases of projects named docker-something or Windows Subsystem for Linux, a name that technically doesn't make sense but "for X" names are usually OK.
> The USPTO initially rejected our application as confusingly similar to the existing trademark on GitHub, which was filed in 2008. While one might imagine where the "Git" in GitHub comes from, by the time we applied to the USPTO, both marks had been widely used in parallel for years. So we worked out an agreement with GitHub which basically says "we are mutually OK with the other trademark existing".
I've been using NixOS for a while now. There is a lot to be said for using nix as a development tool &c, but in terms of a daily driver OS:
Upside: It really is the best of both worlds for binary/source distros. 99% of the time it just downloads an archive and unpacks it, so it's just as fast to install or upgrade as e.g. arch. On the other hand, patching software from upstream takes seconds to do (not counting the unavoidable build time).
Downside: In order to accomplish the upside, it completely changes the filesystem layout. "./configure; make; sudo make install" is basically guaranteed to not work. To install software not in nix, you will be writing a nix expression. There is a command to create an FHS compatible namespace that works for e.g. Steam, but applications installed in there are second-class citizens, so it's preferred to not do this for anything that can simply be installed via a Nix expression.
As someone who hasn't actively used nixos (yet), only nix (the package manager) for a while:
I have always been curious and dumbfounded why he (Eelco) abandoned Maak (his build system, that I thought, would go together with nix). I think a proper, integrated build system (integrated with nix, the package manager) is a (or the?) missing piece to improve software development.
My two current favorite make replacements are redo and tup.
They go in opposite directions in replacing make:
redo boils down to "How can we capture 99% of the value of make with 1% of the complexity" and does it well. It helps that you don't have to figure out whether sh or make will be interpreting your (similar, yet different enough to trip you up) expressions; redo is "sh all the way down" It also manages to automatically have dependencies on build rules which Make could really use.
Tup is more like "How can we limit what make can do in order to make a better special purpose tool?" Tup can't handle files with spaces and implementing "make install" is flat out impossible. It also is very inflexible with your directory tree. However, it is the best tool for "Many files in, one file out, rebuild if any inputs change" and making this implementation tractable is a specific result of being less flexible than make.
[edit]
Just found the Maak paper:
1) Ports actually does unify building and deployment by using make for deployment
1a) This does require writing (or modifying) makefiles for every single package
2) Nix fits in the same space as Maak, as you use nix both for building and deployment; it just may farm out some of the work to a secondary build system such as make. If you consider the build-script to be the generator (rather than e.g. `cc`) then it maps closely to Maak.
2a) There is no reason I can think of why you couldn't have a nix expression for every single .o file, and have nix-build handle incremental builds for you.
2b) Farming out much of the work to existing build systems is a pragmatic approach to reduce the amount of work needed to create a nix expression. 99% of the time if cmake or autoconf are used, a minimal nix file will give you a mostly working package. This is much more reliable than trying to autoconvert Make (which is composed of two turing complete languages) to some other system.
3) One that the paper claims that only the generators can have complete dependency information (Make, Maak, and Nix all farm out specifying dependency information to the author of the build script; though Nix attempts to prevent you from omitting dependencies by sandboxing), but Tup sidesteps this by sitting between the filesystem and the generator.
Have you tried FreeBSD before? It ships with an awesome binary package manager and a virtual tree of sources for all the packages in the package manager at the same time. You can install the binary (sudo pkg install foo) or cd into the source dir, fetch the sources, patch on a whim, then “make” (even if the project upstream does not use make) and install.
I have used ports (if that is what you are referring to) albeit on a mac. It is very basic, without any of the interesting properties that make nix interesting. It essentially feels like a slightly improved "download && ./configure && make && make install" script.
Ports is great. I have only used FreeBSD lightly, but macports is the only package manager for OS X that has been reliable for me. Nix is not a strict improvement, but it improves things in a lot of directions compared to ports.
Hardcoding dependencies at build-time seems to me like a fundamental first step towards a stable system that has been absent from Linux since the late 90s.
The example of modifying `ls` struck me as something that ought to be possible in any Linux distribution with minimal effort. Instead, we have a situation where most people use binary packages, so the source isn't even available to modify. And even if you run a source-based distro like Gentoo, editing those sources by hand can still be quite intimidating. Version control makes it easier to experiment fearlessly (although it's still possible to brick your system...).
It's really not too hard on a Debian system to build a modified package. All sources should be available if you have the src repos in your sources.list. You just download the src package, modify, rebuild and install. https://wiki.debian.org/BuildingTutorial
1. uncomment the deb-src lines in /etc/apt/sources.list; if you do not have these, simply copy each deb line and have it begin with deb-src.
2. apt-get update
3. apt-get source <packagename>
4. cd <packagename>-<version>
5. (do modifications here)
6. dpkg-buildpackage -us -uc
7. install the .deb packages in the parent directory with dpkg -i
Do note, this does not properly embed your modifications in a patch or whatever, I haven't figured out how to do this and lose my mind at the same time.
btrfs snapshots are the source of all of my OpenSUSE crashes. I'm not sure what the issue is, but eventually it fills up my disk silently with snapshots until the system grinds to a halt.
I have three machines that run OpenSuse, my desktop and two laptops (well, one laptop and one very low-end IdeaPad).
On my desktop, I run into the same problem as you; I think my system partition is just a little small. On the laptops, I have not had any trouble with snapshots.
I do like the idea, though - if an update breaks anything, just roll back to the last working state. Windows did this 15 years ago, it was about time Linux distros started catching up.
To me this looks very similar to running a source based distro (Gentoo,Exherbo,...) with lots of packages using git as a fetch method (Gentoo uses the -9999 version suffix, Exherbo calls them scm packages).
Can anybody tell me when I should use gittup instead? Is it just a matter of size? Is rebuilding significantly faster with gittup due to the automatic rebuilding?
I mean to me it looks that gittup has some serious limitations in its current state (e.g. no 'make') while the others are full blown linux systems.
Isn't this similar to yoctos bitbake? A bunch of package repos with a small build combiner on top.
I'm also curious how else would you do it? The article make it sound unique but this seems like the obvious solution, at least conceptually. How do other distros manage and build their packages?
All the BSD systems[1] have had binary packages (at least optionally) for a while now. On OpenBSD, while the ports tree is still there when needed, the recommended way is to use binary packages.
[1] I am not entirely certain what the situation on DragonflyBSD is, I have not touched it in a long time.
The entire source tree is based off of git submodules and an automatic build system, right? I wonder what would happen if you ran “git submodule —update” (presuming the submodules point to master, though I am unsure if that functionality was around in git when this was published) and then tried to build it with tup.
The documentation is a bit... eclectic.
Tup is a build system that keeps track of what files a command accesses. So if you run make from tup, it can look at every file your makefile reads from, and re-run make if any of those files change. Not that useful, in that example, but when you have it run gcc to make each source file instead, it can automatically rebuild just the files that need to be rebuilt.
Building on top of that, they've set up a git repo with the appropriate "tupfiles" (makefiles) to build linux and enough userspace to get by. It's not so much a linux distribution as a build-system that can build an entire linux distro from source.
The big difference between this and a normal build system is that all your source files can be in the same tree as git submodules, and `tup upd` will rebuild the entire thing, only recompiling code who's source file or shared libraries have changed.
I think it could be a pretty powerful system for a lot of projects, I'm particularly interested in using it for building android images, and firmware for ereaders.