<codemac>davexunit: I exported the autoreconf -ivf rule for myself - was wondering the best way to patch this so I could send it to guix-devel? I'm thinking two patches, one that exports it, and on eth at changes a substantial (albeit not complete) number of packages.
<mark_weaver>codemac: I'm not sure it's worth exporting it, because for any given package (when you know which of those scripts to run), it's trivial.
<codemac>well - the implementation of autoreconf *isn't* a one liner, whereas all the system* calls are
<mark_weaver>in any case, if we added it to any of the common modules, it would force a full rebuild of *everything*, so it would have to be done in the core-updates branch.
<mark_weaver>codemac: it's a one-liner when you know the package and know what command is needed. the more complex procedure is only needed when you don't know anything about the package and need to hunt around heuristically for a script that looks like the right one.
<mark_weaver>if you change *any* of the modules that are automatically imported by build scripts, then *everything* will need to be rebuilt.
<mark_weaver>if you put it in a different module, then you'll need to customize the set of imported modules, which takes more lines than just writing the thing.
<mark_weaver>the thing is, unlike the other build phases, where the GNU build system specifies a standard set of commands to build and install software from a tarball, there is no standard command to bootstrap the raw source from the repo to prepare it for a call to configure. it depends on the package.
<codemac>I understand that, I used to do a lot of packaging for archlinux
<codemac>My patch is more -'s than +'s, I don't think it's a huge deal though either way
<mark_weaver>I get the impression that some part of what I've written above is not being understood.
<mark_weaver>but maybe I'm the one who fails to understand. can you show me to your proposed patch?
<codemac>sure, you may understand everything and I may just be dense
<mark_weaver>for example, look at the 'git-modules' package in emacs.scm
<mark_weaver>see those #:modules and #:imported-modules arguments?
<mark_weaver>that's what you need to do to add another module to the set of imports available to the build phases.
<Jookia>you know it's good because it's 'common' and abstract and useless in domain-specific situations
<rekado->If someone was motivated they could probably add a "GuixRequirement" with a reference to a Guix closure, or something.
<rekado->the rest stays the same as it is really just pipelines.
<rekado->davexunit: at least that's what a cursory look at the "workflows" repository tells me.
<rekado->there is, of course, the danger that the popularity of Docker makes people only use "DockerRequirement" and Docker images ... and then using CWL is equivalent to just using Docker + (somewhat standardised) scripts.
<rekado_>so, texlive-texmf took 207 minutes to build on NFS. I don't know if this is good or bad. What are build time values on your systems?
<rekado_>profile building seems a little faster without deduplication. It's down to about a minute.
<phant0mas>well my connection has some small problems today :P