Pjotr Prins writes: > Hi all, > > 2015 was a good year for GNU Guix - Guix has made immense progress. Some > thoughts for 2016: > > I am a software developer by trade and for years I have struggled with > build systems, such as configure/automake, cmake, Ruby RVM/bundler, > Python virtualenv etc. etc. You probably know I have already ditched > RVM/bundler and virtualenv for GNU Guix which is great :) > > Recently it dawned on me that for programming with GNU Guix there is > no longer a need for configure/automake and cmake either! These tools > really try to address the problem of targetting different (posix) > build environments. If I only target GNU Guix I think a simple make > will do again because there are only a few final targets (test, debug, > install) and GNU Guix resolves all dependencies. This greatly > simplifies the task of the software developer. > > I am not going to let tears over losing these complex build tools. And > being a Linux guy I am happy to only target Linux. The different > virtualization solutions make deployments on different systems quite > easy anyway and trivial with Guix because it comes with all > dependencies. > > Even so, my prediction is that eventually other systems will be > targeted too. Even though there currently is not much GNU Guix > initiative outside Linux/Hurd I think people will start working on > other ports. The Guix/Nix back-end already runs on the BSDs, for > example. So, it is mostly a matter of adapting the Guix front-end.
I appreciate and share your pro-guix enthusiasm, and I share your frustration fighting build and packaging systems, though I think there are some good reasons to have the traditional build tools, with and without Guix. Portability is one nice one, but: - Compiling only the files needed during development is important - It's nice to be able to have a standard way to switch on/off features (see emacs with and without X packages in Guix) - Finding what to link to at compile time Other things I'm sure (standardizing how to run tests and stuff saves some time while packaging, etc). I guess these things could be done through Guix itself. What I'd rather see though is a "./configure && make" compatible interface system for package building which uses Guile as its configuration language. Automake and friends are great when they're working, but I'd love a system that relied less on string-macro expansion and etc when I have to debug them. I think that would be an interesting project. It would be nice to see it happen outside of Guix though, so it could be used more generally. - Chris
