Re: fftw runtime cpu detection
Eric Bavier writes: > I recently discovered that the FFTW library can do runtime cpu > detection. Cool! I'm not familiar with this library, but the patch seems pretty reasonable to me. > In order to do this, the package needs to be configured to build SIMD > "codelets", like how our 'fftw-avx' currently does. Then, based on > the instruction support detected at runtime, make those kernels > available to the fftw "planner" for execution. So, if we choose the right configure flags at build time (for the given architecture), then at runtime, the software will detect the CPU and either perform better or make more features available. Is that right? I see you added the "--enable-sse" configure flag, and it not present before. Why did you add it? -- Chris signature.asc Description: PGP signature
Retaining substitutes
Hello, Pjotr Prins skribis: > On Thu, Apr 05, 2018 at 05:24:12PM +0200, Ludovic Courtès wrote: >> Pjotr Prins skribis: >> >> > I am *not* suggesting we stop testing and stop writing tests. They are >> > extremely important for integration (thought we could do with a lot >> > less and more focussed integration tests - ref Hickey). What I am >> > writing is that we don't have to rerun tests for everyone *once* they >> > succeed *somewhere*. If you have a successful reproducible build and >> > tests on a platform there is really no point in rerunning tests >> > everywhere for the exact same setup. It is a nice property of our FP >> > approach. Proof that it is not necessary is the fact that we >> > distribute substitute binaries without running tests there. What I am >> > proposing in essence is 'substitute tests'. >> >> Understood. >> >> > If tests are so important to rerun: tell me why we are not running >> > tests when substituting binaries? >> >> Because you have a substitute if and only those tests already passed >> somewhere. This is exactly the property we’re interested in, right? > > Yup. Problem is substitutes go away. We don't retain them and I often > encounter that use case. I agree this is a problem. We’ve tweaked ‘guix publish’, our nginx configs, etc. over time to mitigate this, but I suppose we could still do better. When that happens, could you try to gather data about the missing substitutes? Like what packages are missing (where in the stack), and also how old is the Guix commit you’re using. More generally, I think there are connections with telemetry as we discussed it recently: we should be able to monitor our build farms to see concretely how much we’re retaining in high-level terms. FWIW, today, on mirror.hydra.gnu.org, the nginx cache for nars contains 94G (for 3 architectures). On berlin.guixsd.org, /var/cache/guix/publish takes 118G (3 architectures as well), and there’s room left. > Providing test-substitutes is much lighter and can be retained > forever. I understand. Now, I agree with Ricardo that this would target the specific use case where you’re building from source (explicitly disabling substitutes), yet you’d like to avoid running tests. We could adresss this using specific mechanisms (although like I said, I really don’t see what it would look like.) However, I believe optimizing substitute delivery in general would benefit everyone and would also address the running-tests-takes-too-much-time issue. Can we focus on measuring the performance of substitute delivery and thinking about ways to improve it? Thanks for your feedback, Ludo’.
Re: Patching the default PATH of `su`
Hello, Leo Famulari skribis: > In the man page of su(1), it says this: > > -- > The current environment is passed to the new shell. The value of $PATH is > reset to > /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the > superuser. > This may be changed with the ENV_PATH and ENV_SUPATH definitions in > /etc/login.defs. > -- > > This means that `su leo` or `sudo su` give a broken environment on > GuixSD. You have to use `su --login` instead. > > Should we use our own values for ENV_PATH and ENV_SUPATH so that this > works out of the box? Probably, yes. It would be good to check how this affects mingetty/login, sshd, etc. Note that libc also has its own default PATH value in : /* Default search path. */ #define _PATH_DEFPATH "/usr/bin:/bin" /* All standard utilities path. */ #define _PATH_STDPATH \ "/usr/bin:/bin:/usr/sbin:/sbin" Does ‘su’ rely on this? In a future rebuild cycle we could change these values, but /run/current-system/bin wouldn’t work on foreign distros, so it’s not clear there’s much to gain. Thanks, Ludo’.
Re: fftw runtime cpu detection
Hello Eric, Eric Bavier skribis: > I recently discovered that the FFTW library can do runtime cpu > detection. In order to do this, the package needs to be configured to > build SIMD "codelets", like how our 'fftw-avx' currently does. Then, > based on the instruction support detected at runtime, make those > kernels available to the fftw "planner" for execution. That’s really good news! Thanks for testing it. The patch LGTM. Can you confirm that the planner won’t ever try to use the AVX2 codelets, for instance when running the test suite on an x86_64 box that lacks AVX2? If that’s the case, I’d be in favor of pushing this patch to core-updates. Thanks, Ludo’.
Re: Treating tests as special case
Pjotr Prins writes: > Ludo is correct that provisioning binary substitutes is one solution. > But not cheap. Can we guarantee keeping all substitutes? At least the > ones with long running tests ;). For berlin.guixsd.org we have an external storage array of a couple of TB, which currently isn’t attached (I’ll get around to it some day). We can keep quite a few substitutes with that amount of space. > Even so, with my idea of test substitutes you don't have to opt out of > testing. And you would still have found that bug. Those who care can > test all they please. I am not sure there’s an easy implementation that allows us to make tests optional safely. They are part of the derivation. We could make execution dependent on an environment variable that is set or not by the daemon, I suppose. > One suggestion: let's also look at tests that are *not* about > integration or hardware/kernel configuration and allow for running them > optionally. Stupidly running all tests that people come up with is not > a great idea. We just run what authors decide that should be run. We’ve already trimmed some of the longer test suites. There are some libraries and applications that have different test suites for different purposes, and in those cases we picked something lighter and more appropriate for our purposes. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Treating tests as special case
Pjotr Prins writes: > I think we should have a switch for turning off tests. Let the builder > decide what is good or bad. Too much nannying serves no one. I think it would be OK to give users the choice of not running tests when building from source, if they really don't want to. This is similar to how users can choose to skip the "make check" step (and live with the risk) when building something manually. However, I think we should always run the tests by default. Maybe you could submit a patch to add a "--no-tests" option? l...@gnu.org (Ludovic Courtès) writes: > That is why I was suggesting putting effort in improving substitute > delivery rather than trying to come up with special mechanisms. Yes, I think that improving substitute availability is the best path forward. I'm willing to bet that Pjotr would not be so frustrated if substitutes were consistently available. Regarding Pjotr's suggestion to add a "test result substitute" feature: It isn't clear to me how a "test result substitute" is any better than a substitute in the usual sense. It sounds like Pjotr is arguing that if the substitute server can tell me that a package's tests have passed, then I don't need to run the tests a second time. But why would I have to build the package from source in that case, anyway? Assuming the substitute server has told me that the package's tests have passed, it is almost certainly the case that the package has been built and its substitute is currently available, so I don't have to build the package myself - I can just download the substitute! Conversely, if a substitute server says the tests have not passed, then certainly no substitute will be available, so I'll have to build it (and run the tests) myself. Perhaps I am missing something, but it does not seem to me that the existence of a "test result substitute" would add value. I think what Pjotr really wants is (1) better substitute availability, or (2) the option to skip tests when he has to build from source because substitutes are not available. I think (1) is the best goal, and (2) is a reasonable request in line with Guix's goal of giving control to the user. Ricardo Wurmus skribis: > An idea that came up on #guix several months ago was to separate the > building of packages from testing. Testing would be a continuation of > the build, like grafts could be envisioned as a continuation of the > build. What problems would that solve? Pjotr Prins writes: > The building takes long enough. Testing takes incredibly long with > many packages (especially language related) and are usually single > core (unlike the build). Eelco told me that in Nix, they set --max-jobs to the number of CPU cores, and --cores to 1, since lots of software has concurrency bugs that are easier to work around by building on a single core. Notably, Guix does the opposite: we set --max-jobs to 1 and --cores to the number of CPU cores. I wonder if you would see faster builds by adjusting these options for your use case? > It is also bad for our carbon foot print. Assuming everyone uses Guix > on the planet, is that where we want to end up? When everyone uses Guix on the planet, substitutes will be ubiquitous. You'll be able to skip the tests because, in practice, substitutes will always be available (which means an authorized substitute server ran the tests successfully). Or, if you are very concerned about correctness, you might STILL choose to build from source - AND run the tests - because you are concerned that your particular circumstances (kernel version, file system type, hardware, etc.) was not tested by the build farm. > I know there are two 'inputs' I am not accounting for: (1) hardware > variants and (2) the Linux kernel. But, honestly, I do not think we > are in the business of testing those. We can assume these work. Even if those components worked for the maintainers who ran the tests on their own machines and made a release, they might not work correctly in your own situation. Mark's story is a great example of this! For this reason, some people will still choose to build things from source themselves, even if substitutes are available from some other place. -- Chris signature.asc Description: PGP signature
a blog post
Hello fellow guixers, I posted a brand new post in my little personal somewhat indie blog It's about Guix, Guile and Free Software in general. From my very own point of view You can find it here http://catonano.v22018025836661967.nicesrv.de/guile-and-free-software.html There's also a feed, reachable here http://catonano.v22018025836661967.nicesrv.de/feed.xml I hope you're not bothered by this shamelessly self promotional post on the mailing list But I remember Ludo saying that not only new packages and services would be needed for the future of Guix but also community oriented stuff such as blog posts and maybe screencasts and so on The blog is made with Haunt and it's completely Javascript free. This should make the consultation easier from Tor Too bad I couldn't take care of the fonts yet so it still points to some Google provided fonts 😓 Also, I host it on a vps by netcup.de, a German provider, I don't know how that fares with Tor either. I hope not too bad So, this is it Thanks
Re: Python applications that are also libraries
Ricardo Wurmus writes: > we have a bunch of packages that are used both as applications and as > Python libraries. An example is “deeptools”. I took a brief peek at deeptools. It looks like there are programs in bin, and libraries in lib. Why can't we just split them into two outputs? For example, put the libraries into the default "out" output and the programs into the "bin" output. -- Chris signature.asc Description: PGP signature
Re: Python applications that are also libraries
Am 06.04.2018 um 11:12 schrieb Chris Marusich: > Why can't we just split them into two > outputs? For example, put the libraries into the default "out" output > and the programs into the "bin" output. For consistence, we should then do this for all other python packages including a script, e.g. sphinx and a lot others. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Patching the default PATH of `su`
On Fri, Apr 06, 2018 at 10:01:57AM +0200, Ludovic Courtès wrote: > Probably, yes. It would be good to check how this affects > mingetty/login, sshd, etc. Okay. I can test the change. > Note that libc also has its own default PATH value in : > > /* Default search path. */ > #define _PATH_DEFPATH "/usr/bin:/bin" > /* All standard utilities path. */ > #define _PATH_STDPATH \ > "/usr/bin:/bin:/usr/sbin:/sbin" > > Does ‘su’ rely on this? In a future rebuild cycle we could change these > values, but /run/current-system/bin wouldn’t work on foreign distros, so > it’s not clear there’s much to gain. I don't think `su` uses this, but I'll find out. As you say, it wouldn't help much on foreign distros. I think the situation with `su` is different, since it seems inconvenient to use our `su` on a foreign distro, because it needs to be setuid. signature.asc Description: PGP signature
Re: Treating tests as special case
Hi Björn, > On Thu, 05 Apr 2018 12:14:53 +0200 > Ricardo Wurmus wrote: > >> Björn Höfling writes: >> >> > And you mentioned different environment conditions like machine and >> > kernel. We still have "only" 70-90% reproducibility. >> >> Where does that number come from? In my tests for a non-trivial set >> of bioinfo pipelines I got to 97.7% reproducibility (or 95.2% if you >> include very minor problems) for 355 direct inputs. >> >> I rebuilt on three different machines. > > I have no own numbers but checked Ludivic's blog post from October 2017: > > https://www.gnu.org/software/guix/blog/2017/reproducible-builds-a-status-update/ > > "We’re somewhere between 78% and 91%—not as good as Debian yet, [..]". Ah, I see. Back then we didn’t have a fix for Python bytecode, which affects a large number of packages in Guix but not on Debian (who simply don’t distribute bytecode AFAIU). > So if your numbers are valid for the whole repository, that is good > news and would mean we are now better than Debian [1], and that would > be worth a new blog post. The analysis was only done for the “pigx” package and its direct/propagated inputs. I’d like to investigate the sources of non-determinism for remaining packages and fix them one by one. For some we already know what’s wrong (e.g. for Haskell packages the random order of packages in the database seems to be responsible), but for others we haven’t made an effort to look closely enough. I’d also take the Debian numbers with a spoonful of salt (and then take probiotics in an effort to undo some of the damage, see[1]), because they aren’t actually rebuilding all Debian packages. [1]: https://insights.mdc-berlin.de/en/2017/11/gut-bacteria-sensitive-salt/ -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Python applications that are also libraries
Chris Marusich writes: > Ricardo Wurmus writes: > >> we have a bunch of packages that are used both as applications and as >> Python libraries. An example is “deeptools”. > > I took a brief peek at deeptools. It looks like there are programs in > bin, and libraries in lib. Why can't we just split them into two > outputs? For example, put the libraries into the default "out" output > and the programs into the "bin" output. The programs in “bin” use the libraries in “lib”. The binaries aren’t big, so separating them from the lib output provides hardly any benefit. The point here is that in the library case inputs must be propagated, whereas in the case where only the executables are used the inputs don’t have to be propagated. Separating them in two outputs doesn’t address this problem as far as I can see. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Looking for Thunderbird/Icedove
FYI, here's my current WIP patch to add Icedove. It's currently stuck
on the same issue that Nils reported being stuck on, but it's based on
our existing IceCat package and already includes most (maybe all?) of
the Icedove rebranding and FSDG fixes from Parabola.
This is currently based on core-updates, but it should apply to master
without difficultly. It also contains a few small untested changes to
the 'icecat' package.
I intend to continue working on this.
Mark
>From 47fbd170b9d3718ff3a343ff362b6c9ca2150fa6 Mon Sep 17 00:00:00 2001
From: Mark H Weaver
Date: Thu, 5 Apr 2018 16:34:50 -0400
Subject: [PATCH] WIP: gnu: Add icedove.
---
gnu/local.mk | 5 +
gnu/packages/gnuzilla.scm | 216 +-
gnu/packages/patches/icedove-CVE-2018-5148.patch | 53 +++
.../patches/icedove-avoid-bundled-libraries.patch | 35 ++
gnu/packages/patches/icedove-libre.patch | 448 +
.../patches/icedove-use-system-graphite2.patch | 250
.../patches/icedove-use-system-harfbuzz.patch | 281 +
7 files changed, 1287 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/icedove-CVE-2018-5148.patch
create mode 100644 gnu/packages/patches/icedove-avoid-bundled-libraries.patch
create mode 100644 gnu/packages/patches/icedove-libre.patch
create mode 100644 gnu/packages/patches/icedove-use-system-graphite2.patch
create mode 100644 gnu/packages/patches/icedove-use-system-harfbuzz.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index 7697a37b1..6cf49ad07 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -793,6 +793,11 @@ dist_patch_DATA = \
%D%/packages/patches/icecat-avoid-bundled-libraries.patch \
%D%/packages/patches/icecat-use-system-graphite2.patch \
%D%/packages/patches/icecat-use-system-harfbuzz.patch \
+ %D%/packages/patches/icedove-CVE-2018-5148.patch \
+ %D%/packages/patches/icedove-avoid-bundled-libraries.patch \
+ %D%/packages/patches/icedove-libre.patch \
+ %D%/packages/patches/icedove-use-system-graphite2.patch \
+ %D%/packages/patches/icedove-use-system-harfbuzz.patch \
%D%/packages/patches/id3lib-CVE-2007-4460.patch \
%D%/packages/patches/ilmbase-fix-tests.patch \
%D%/packages/patches/intltool-perl-compatibility.patch \
diff --git a/gnu/packages/gnuzilla.scm b/gnu/packages/gnuzilla.scm
index b4789d687..52ff09745 100644
--- a/gnu/packages/gnuzilla.scm
+++ b/gnu/packages/gnuzilla.scm
@@ -31,6 +31,7 @@
#:use-module ((guix licenses) #:prefix license:)
#:use-module (guix packages)
#:use-module (guix download)
+ #:use-module (guix git-download)
#:use-module (guix utils)
#:use-module (guix build-system gnu)
#:use-module (gnu packages autotools)
@@ -563,10 +564,18 @@ security standards.")
#:validate-runpath? #f
#:configure-flags '("--enable-default-toolkit=cairo-gtk3"
+
+ "--with-distribution-id=org.gnu"
+
"--enable-gio"
"--enable-startup-notification"
"--enable-pulseaudio"
+ "--disable-tests"
+ "--disable-updater"
+ "--disable-crashreporter"
+ "--disable-maintenance-service"
+ "--disable-eme"
"--disable-gconf"
"--disable-gnomeui"
@@ -639,7 +648,7 @@ security standards.")
(close-port out))
#t))
(add-after
- 'unpack 'arrange-to-link-libxul-with-libraries-it-might-dlopen
+ 'unpack 'link-libxul-with-libraries
(lambda _
;; libxul.so dynamically opens libraries, so here we explicitly
;; link them into libxul.so instead.
@@ -754,3 +763,208 @@ features built-in privacy-protecting features.")
`((ftp-directory . "/gnu/gnuzilla")
(cpe-name . "firefox_esr")
(cpe-version . ,(first (string-split version #\-)))
+
+(define-public icedove
+ (package
+(name "icedove")
+(version "52.7.0")
+(source (origin
+ (method url-fetch)
+ (uri (string-append "https://ftp.mozilla.org/pub/mozilla.org/";
+ "thunderbird/releases/" version "/source/"
+ "thunderbird-" version ".source.tar.xz"))
+ (sha256
+ (base32 "18rf576mhx9sf4g0gdb22mnpnssrcrhlm4i66b07ivcksf82hil2"))
+ (patches (search-patches "icedove-avoid-bundled-libraries.patch"
+ "icedove-use-system-harfbuzz.patch"
+ "icedove-use-system-graphite2.patch"
+ "icedove-libre.patch"
+ "icedove-CVE-2018-5148.patch"))
+ (modules (origin-modules (package-source iceca
Re: fftw runtime cpu detection
On Fri, Apr 06, 2018 at 10:05:43AM +0200, Ludovic Courtès wrote: > Hello Eric, > > Eric Bavier skribis: > > > I recently discovered that the FFTW library can do runtime cpu > > detection. In order to do this, the package needs to be configured to > > build SIMD "codelets", like how our 'fftw-avx' currently does. Then, > > based on the instruction support detected at runtime, make those > > kernels available to the fftw "planner" for execution. > > That’s really good news! Thanks for testing it. > > The patch LGTM. Can you confirm that the planner won’t ever try to use > the AVX2 codelets, for instance when running the test suite on an x86_64 > box that lacks AVX2? Yes, I've successfully run 'make check' on an sse2-only machine where '--enable-avx' and '--enable-avx2' where configured. I'll check on an i686 machine tonight. > If that’s the case, I’d be in favor of pushing this patch to core-updates. Great. I'll do some more testing. Should I send a finalized patch to guix-patches when it's ready? -- Eric Bavier, Scientific Libraries, Cray Inc.
Re: fftw runtime cpu detection
On Fri, Apr 06, 2018 at 12:54:19AM -0700, Chris Marusich wrote: > Eric Bavier writes: > > > I recently discovered that the FFTW library can do runtime cpu > > detection. > > Cool! I'm not familiar with this library, but the patch seems pretty > reasonable to me. Thanks for looking at it. > > In order to do this, the package needs to be configured to build SIMD > > "codelets", like how our 'fftw-avx' currently does. Then, based on > > the instruction support detected at runtime, make those kernels > > available to the fftw "planner" for execution. > > So, if we choose the right configure flags at build time (for the given > architecture), then at runtime, the software will detect the CPU and > either perform better or make more features available. Is that right? That's the idea, yes. The simd kernels will execute if the cpu supports them and the fftw planner finds they are faster in practice than other kernels. > > I see you added the "--enable-sse" configure flag, and it not present > before. Why did you add it? > In the documentation, I had seen it listed as the simd flag for single-precision. But now I see a comment in configure.ac that says the --enable-sse2 flag Does The Right Thing when --enable-float is given, so it can be left out. Thanks for checking! -- Eric Bavier, Scientific Libraries, Cray Inc.
Re: fftw runtime cpu detection
Eric Bavier skribis: > On Fri, Apr 06, 2018 at 10:05:43AM +0200, Ludovic Courtès wrote: >> Hello Eric, >> >> Eric Bavier skribis: >> >> > I recently discovered that the FFTW library can do runtime cpu >> > detection. In order to do this, the package needs to be configured to >> > build SIMD "codelets", like how our 'fftw-avx' currently does. Then, >> > based on the instruction support detected at runtime, make those >> > kernels available to the fftw "planner" for execution. >> >> That’s really good news! Thanks for testing it. >> >> The patch LGTM. Can you confirm that the planner won’t ever try to use >> the AVX2 codelets, for instance when running the test suite on an x86_64 >> box that lacks AVX2? > > Yes, I've successfully run 'make check' on an sse2-only machine where > '--enable-avx' and '--enable-avx2' where configured. I'll check on an > i686 machine tonight. OK. >> If that’s the case, I’d be in favor of pushing this patch to core-updates. > > Great. I'll do some more testing. Should I send a finalized patch to > guix-patches when it's ready? If Marius has no objections, I think you could push it directly to core-updates. Thank you, Ludo’.
Re: Treating tests as special case
Hello, > > An idea that came up on #guix several months ago was to separate the > > building of packages from testing. Testing would be a continuation of > > the build, like grafts could be envisioned as a continuation of the > > build. > What problems would that solve? If one can run tests suites locally upon built packages, that would already save quite a great deal of planet heat I guess, not building from the source in the first place, but only if they find a bug, fix it ... - and iiuc, Mark would have found the bug he mentioned ... > Even if those components worked for the maintainers who ran the tests on > their own machines and made a release, they might not work correctly in > your own situation. Mark's story is a great example of this! For this > reason, some people will still choose to build things from source > themselves, even if substitutes are available from some other place. But they would rebuild from the source just to run the tests? Sounds to me that, if possible, separate test suites from the building process is an added value to the current situation Cheers, David pgpPP0fq9Q3_6.pgp Description: OpenPGP digital signature
Re: fftw runtime cpu detection
Ludovic Courtès writes: > Eric Bavier skribis: > >> On Fri, Apr 06, 2018 at 10:05:43AM +0200, Ludovic Courtès wrote: >> >>> If that’s the case, I’d be in favor of pushing this patch to core-updates. >> >> Great. I'll do some more testing. Should I send a finalized patch to >> guix-patches when it's ready? > > If Marius has no objections, I think you could push it directly to > core-updates. Sounds good to me. I just pushed a couple of full-rebuild commits to fix bootstrap-tarballs, so the Big Rebuild is still some days off. signature.asc Description: PGP signature
Re: [PATCH] gnu: Add systemd.
Ludovic Courtès writes: > That said, if the package can be of any use, I don’t have any objections > to its inclusion, especially after all the hard work that Marius and the > reviewers put in it. ;-) FWIW I think my work already paid off plenty ;-) > I suspect the only use case that might work would be running it as an > unprivileged user, right? Would that make sense? Out of curiosity, I tried this: $ /gnu/store/1f6rib753hvxpxqdih1m3zhhsiw4r91n-systemd-238/lib/systemd/systemd --user Trying to run as user instance, but the system has not been booted with systemd. So that does not work either. > We’d also have to make sure someone will maintain it though, which is > probably a bit of work. It might as well bitrot on guix-devel instead of in the repository IMO. It could be fun to add a (gnu packages jokes) module though... signature.asc Description: PGP signature
Autotools formely: a blog post
Hi Catano, Thanks for the blog. Indeed, I love working with Guix and developing with Guix. Guix takes care of my deployment and configuration requirements. I have written some time in the past that with Guix you don't need autotools. The main thing autotools solve is configuring the build for an environment. At the same time, with Guix you get a predictable environment, so a make file (or similar) suffices. It is what I do in all my development projects - I don't use autotools to develop and deploy them. It greatly simplifies my existence :). Indeed, I have never liked autotools (essentially a nasty hack) and only used them before Nix/Guix. So, my approach is the same as yours :) You can do without autotools once inside Guix and once you decide to ignore targeting other distributions. Which I do, though I have ways of deploying Guix built packages on other systems without Guix which people also use. E.g. https://github.com/genetics-statistics/GEMMA/releases The top files include a binary Guix package installer. You can try it. It is a way of distributing pre-built code on other systems. If you are interested you could package your stuff too. Though it probably makes less sense for a library for Guile until it becomes something accepted by the Guile ecosystem. Pj.
Re: a blog post
Hello Catonano, Thanks for the blog post, I added your feed to my feed reader. I understand your frustration with autotools, it can be difficult to figure out how to get autotools to do what you want. The benefit of autotools is that it creates the same interface to build, test, and install GNU software (of course if implemented the correctly...). This interface usually makes it easier for others to package for their distribution. What I think we need to do to improve Guile's chances for success is to take a serious look at our tools and practices, improve them if needed, and document the best ways to set up Guile and use it. Guix is great, but we can't forget Guile users who don't use Guix. This probably includes packaging Guile libraries for these other package managers. - Erik (OrangeShark)
