6 ms·

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... eclecti

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.

xiaq 9y ago
> It's not so much a linux distribution as a build-system that can build an entire linux distro from source. Isn't a Linux distro largely defined by its packaging system, which in turn is largely defined by how software is built from source?
- traverseda 9y ago
  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.
  - ComputerGuru 9y ago
    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.
    - DSMan195276 9y ago
      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. [0] https://groups.google.com/d/msg/tup-users/Kxw1nnXK12o/my4IYt8OnzsJ https://groups.google.com/d/msg/tup-users/Kxw1nnXK12o/my4IYt...
      - ComputerGuru 9y ago
        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.)
        DSMan195276 9y ago
        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.
        9y ago
- kbenson 9y ago
  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.
  - saghm 9y ago
    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
    - kbenson 9y ago
      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.
      - jldugger 9y ago
        Even now, Ubuntu releases start largely by forking debian unstable.
equalunique 9y ago
Page says it's only for x86, but hopefully this will be extended to other architectures. :D

xiaq 9y ago

> It's not so much a linux distribution as a build-system that can build an entire linux distro from source. Isn't a Linux distro largely defined by its packaging system, which in turn is largely defined by how software is built from source?

traverseda 9y ago
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.
- ComputerGuru 9y ago
  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.
  - DSMan195276 9y ago
    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. [0] https://groups.google.com/d/msg/tup-users/Kxw1nnXK12o/my4IYt8OnzsJ https://groups.google.com/d/msg/tup-users/Kxw1nnXK12o/my4IYt...
    - ComputerGuru 9y ago
      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.)
      - DSMan195276 9y ago
        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.
        9y ago
kbenson 9y ago
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.
- saghm 9y ago
  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
  - kbenson 9y ago
    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.
    - jldugger 9y ago
      Even now, Ubuntu releases start largely by forking debian unstable.

equalunique 9y ago

Page says it's only for x86, but hopefully this will be extended to other architectures. :D