4 ms·

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.
      - rkangel 9y ago
        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.
        dilap 9y ago
        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
      - jdonaldson 9y ago
        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 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?

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.
    - rkangel 9y ago
      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.
      - dilap 9y ago
        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
    - jdonaldson 9y ago
      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 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?