Hi!
Ben Woodcroft <address@hidden> skribis:
I'm a little late here, but please do all of the things on that list :)
:-)
With this suggestion:
+ for
[[https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00005.html][CPU-specific
optimizations]]
+ somehow support -mtune=native (and even profile-guided
optimizations?)
I'm not sure if you already thought of this, but an important use case is that
of pipelines, where we may want to optimise not just the package being built,
but instead one (or more) of its dependencies. So your suggestion of this
syntax:
guix package --tune=haswell -i diamond
requires some extensions, maybe something like this, where bamm can be used as
a pipeline that uses bwa and samtools:
guix package -i bamm --tune=haswell bwa samtools
and to optimise the C in bamm itself too:
guix package -i bamm --tune=haswell bwa samtools bamm
So you’re saying that --tune should apply recursively, right?
On 01/11/16 17:15, Ricardo Wurmus wrote:
[...]
I strongly encourage users to do two things:
- use manifests
- record the current version of Guix and our local package repository
when instantiating a manifest. It only takes these two pieces of
information to reproduce a software environment
Is it possible to help automate this process somehow e.g. by checking
if packages in GUIX_PACKAGE_PATH are within git repositories and
reporting their statuses?
It would be nice.
As you note, there’s a design question that needs to be discussed. On
one hand, Guix doesn’t need to know and care about how things in
$GUIX_PACKAGE_PATH were obtained, etc. On the other hand, if Guix would
manage such external repos by itself, it would be able to give more
precise information on what’s being used and to provide more featureful
tools.
This is related to the idea of “channels” that we’ve been discussing
notably with Pjotr.