From: zimoun <zimon.toutoune@gmail.com>
To: ison <ison@airmail.cc>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Parameterized packages
Date: Fri, 17 Jan 2020 16:53:58 +0100 [thread overview]
Message-ID: <CAJ3okZ23X5Y10XN+gReoiyM+766BUMNW4BqCWQqHHpMr6piMRA@mail.gmail.com> (raw)
In-Reply-To: <20200116190644.uytvzvypuvdwh2iq@n0>
On Thu, 16 Jan 2020 at 20:06, ison <ison@airmail.cc> wrote:
> On Wed, Jan 15, 2020 at 02:54:25PM +0100, zimoun wrote:
> > And what I was thinking is a mechanism to easily set some arguments to
> > the build-system; for example changing the compiler toolchain (say
> > replacing GCC by Clang/LLVM).
> >
> > Well, as I said, I do not know if it is related to "parametrized
> > packages" because I am not sure to understand the final aim for these
> > "parametrized packages". :-)
[...]
> That is, simplify the problem to the mere concept of passing arguments to
> functions and nothing more. Take the headless server example: some parameter
> is passed to a package such as
> '("-X")
> That package would then be entirely responsible for what to do with them. If
> the package decides not to pass the same parameters to its inputs then the
> inputs are simply built without any parameters.
I agree.
What I was trying to suggest and/or discuss is to see the build-system
as a function where the compiler toolset is one argument.
Let consider these "compilers" (associated with complete toolset for
"compiling"): OCaml@4.01, OCaml@4.07, OCaml@4.09, CPython@2.7,
CPython@3.5, CPython@3.6, PyPy (not yet in Guix), GCC@8, GCC@9,
Clang@8, Clang@9, etc.
Today, for one particular build system, the compiler is fixed. To use
another compiler than the default one, the trick is to have
'package-with-explicit' and each build-system has to provide
'package-with-<version>' where <version> is hard coded.
To be clear, the seed (bootstrap) fixes how the compilers OCaml@4.01,
OCaml@4.07, OCaml@4.09, CPython@2.7, CPython@3.5, CPython@3.6, PyPy
(not yet in Guix), GCC@8, GCC@9, Clang@8, Clang@9, etc are compiled.
Then, it is difficult to use them to compile a package with one of
them.
Do we end with 'package-with-ocaml4.01', 'package-with-ocaml4.07',
'package-with-ocaml4.09', 'package-with-python2',
'package-with-python3.5', 'package-with-python3.6',
'package-with-pypy', 'package-with-gcc8', 'package-with-gcc9', etc.?
Do the users have to write all these 'package-with-<version>'?
And if one wants to use CPython@3.5 and GCC@8, does they need to
define the package using:
(define-public my-foo
(package-with-python3.5
(package-with-gcc8 foo)))
?
I feel something is lacking.
And do not take me wrong, I am not suggesting that Guix should
maintain and ensure it works for all the combinations. The default is
already enough! :-)
And yes, it means potentially recompiling the world. Try to plot "guix
graph -t bag-emerged foo". ;-)
Why do I want that?
For example, a couple of software have been used to simulate complex
physical phenomena. Using the commit A -- which provides the seed A
and all compiling tools in the version X -- I get some results. Then
using the commit B -- which provided the seed B and all the compiling
tools in the version Y -- I get different results. Where does come
from the difference? From my couple of software which are not
reproducible? From round-off errors and floating point arithmetic
mess? Well, the most probable... but can I reduce the search space of
the difference? And I would like to be able to fix the seed to A, then
used the compiling tools in the version X and compare using this very
same seed A with the compiling tools in the version Y. Do the same
with seed B.
Well, it would ease comparison in the HPC world. :-)
It is not related to the "parametrized package" in the sense of flag
options. :-)
And I do not know if it make sense. What do you think?
All the best,
simon
next prev parent reply other threads:[~2020-01-17 15:54 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-14 11:54 Parameterized packages Ludovic Courtès
2019-05-14 15:17 ` Tobias Geerinckx-Rice
2019-05-17 14:23 ` Pierre Neidhardt
2019-05-17 18:15 ` Mark H Weaver
2019-07-19 5:41 ` Chris Marusich
2019-07-19 20:29 ` ison
2020-01-02 19:23 ` Pierre Neidhardt
2020-01-09 11:10 ` Pierre Neidhardt
2020-01-09 23:13 ` Marius Bakke
2020-01-10 12:29 ` Pierre Neidhardt
2020-01-10 16:19 ` Ludovic Courtès
2020-01-11 11:31 ` Pierre Neidhardt
2020-01-14 15:05 ` zimoun
2020-01-15 9:40 ` Pierre Neidhardt
2020-01-15 11:30 ` zimoun
2020-01-15 11:51 ` Pierre Neidhardt
2020-01-15 13:54 ` zimoun
2020-01-16 19:06 ` ison
2020-01-16 20:55 ` Ricardo Wurmus
2020-01-17 16:34 ` Pierre Neidhardt
2020-01-17 9:15 ` L p R n d n
2020-01-17 16:46 ` Pierre Neidhardt
2020-01-17 15:53 ` zimoun [this message]
2020-01-17 16:56 ` Pierre Neidhardt
2020-01-20 14:34 ` zimoun
2020-01-21 10:56 ` Build systems and implicit inputs Ludovic Courtès
2020-01-21 12:24 ` zimoun
2020-01-21 13:07 ` Pierre Neidhardt
2020-01-21 18:02 ` zimoun
2020-01-19 20:34 ` Parameterized packages Ludovic Courtès
2020-01-20 9:08 ` Pierre Neidhardt
2020-01-20 14:50 ` zimoun
2020-01-20 18:57 ` Pierre Neidhardt
2020-01-20 19:07 ` Pierre Neidhardt
2020-01-20 22:57 ` ison
2020-01-21 10:09 ` Pierre Neidhardt
2020-01-21 10:49 ` Ludovic Courtès
2020-01-21 12:15 ` zimoun
2020-01-21 13:13 ` Pierre Neidhardt
2020-01-21 19:04 ` zimoun
2020-01-22 9:54 ` Pierre Neidhardt
2020-01-22 12:23 ` zimoun
2020-01-24 21:56 ` ison
2020-01-26 19:35 ` zimoun
2020-01-27 10:13 ` Pierre Neidhardt
2020-01-27 11:23 ` zimoun
2020-01-27 11:50 ` Pierre Neidhardt
2020-01-27 12:34 ` zimoun
2020-01-27 10:04 ` Pierre Neidhardt
2020-01-25 18:52 ` John Soo
2020-01-27 10:17 ` Pierre Neidhardt
2020-01-20 14:12 ` zimoun
2020-01-17 16:31 ` Pierre Neidhardt
[not found] ` <875zhbvzfz.fsf@guixSD.i-did-not-set--mail-host-address--so-tickle-me>
2020-01-17 16:41 ` Pierre Neidhardt
2020-01-19 20:30 ` Ludovic Courtès
2020-01-15 11:43 ` Pierre Neidhardt
2020-01-15 11:44 ` Pierre Neidhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJ3okZ23X5Y10XN+gReoiyM+766BUMNW4BqCWQqHHpMr6piMRA@mail.gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ison@airmail.cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.