*Intro:* First, thanks for tup! Also thanks for having a version available on Debian/Ubuntu.
Below I describe a few ways I've hacked tup's build for my own needs. I also found it a bit confusing and tricky to build a package for my own PPA, so I created my own setup on Launchpad. *Overview:* For what it's worth, I adapted the build to use CMake. Here it is: https://gist.github.com/e2/5e1a35ffef7d6b58247554dbc8cee50e The catch: only Linux support. Because I don't use anything else. (I theoretically could test it on *BSD, but I'm not not that willing to). The upside: only about 120 lines of code, no deb-helper hacks, and most of the code will likely be quite portable. *Changes and reasons:* I also removed the included sqlite3 and lua sources. (External packages are used instead). Yes, I broke the patched lua functionality, but I believe that should be in a separate repository anyway. I don't really use the Lua part myself, while I really needed an updated package I could deploy in Docker (without git + deps + building). I thought the build system had way to many hacks necessary to get it build using tup. The idea of "building a tool with itself" always seems like a good one at first, but it usually quickly discourages contributors. (IMHO). *Status:* Works - except for what's covered by the lua patch. (Which I personally don't care about). I created a custom PPA here: https://launchpad.net/~cezary0/+archive/ubuntu/tup (It's based on the latest released tarball from GitHub). The list of commits (debian/*) and patches (quilt) I used are here: http://bazaar.launchpad.net/~cezary0/+junk/tup-cmake-linux-only/changes *My thoughts:* If I was a maintainer of Tup and I wanted to make the project more welcoming for new users/contributors, I'd: - remove the usage of Tup from the build (as I did by switching to CMake) - instead, I'd change the docs to have lots of "recipes" instead - there's lots of humor on the website, but that doesn't really help me answer questions or get things done - reduce the list of open issues (it's so long, it's discouraging) - by mergin/closing as much as possible - add a separate repository for debian/* files (it just makes more sense) - either merge or close all the pull requests - improve the error messages so it's easier to understand "what went wrong" and "what I probably should do" - make the parts easier to reuse - e.g. I should be able to opt-out of Lua if I want. Or easily create binding for whatever I need without diverging from the codebase too much. *Feature requests:* *- *probably only allowing directory listing on the fuse filesystem Yes, it's probably not a good idea for build systems, though treating a directory just like an "input file" does have it's merits. Anyway, have a nice day! -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
