Hi,
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
On 01/11/16 17:15, Ricardo Wurmus wrote:
myglc2 <myg...@gmail.com> writes:
On 10/26/2016 at 14:08 Ricardo Wurmus writes:
At the MDC we’re using SGE and users specify their software environment
in the job script. The software environment is a Guix profile, so the
job script usually contains a line to source the profile’s
“etc/profile”, which has the effect of setting up the required
environment variables.
Cool. How do you deal with the tendency of user's profiles to be "moving
targets?" IOW, I am wondering how one would reproduce a result at a
later date when one's profile has "changed"?
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? Or is that too much tie-in with git? Tie-in with git
would also be useful because 'guix lint' could be used to check
correctness of git commit messages, etc.
ben