From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: Re: Parameterized packages Date: Fri, 17 Jan 2020 16:53:58 +0100 Message-ID: References: <8736ldq74z.fsf@netris.org> <20190719202906.lbanx5puk7t6q4cr@cf0> <87a7753boq.fsf@ambrevar.xyz> <87h813wah0.fsf@gnu.org> <87v9piut40.fsf@ambrevar.xyz> <87o8v5ukgb.fsf@ambrevar.xyz> <87d0blhr9s.fsf@ambrevar.xyz> <20200116190644.uytvzvypuvdwh2iq@n0> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:40558) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1isTwq-0003y5-7f for guix-devel@gnu.org; Fri, 17 Jan 2020 10:54:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1isTwo-0005F9-UP for guix-devel@gnu.org; Fri, 17 Jan 2020 10:54:12 -0500 Received: from mail-qk1-x72d.google.com ([2607:f8b0:4864:20::72d]:37541) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1isTwo-0005E1-Pr for guix-devel@gnu.org; Fri, 17 Jan 2020 10:54:10 -0500 Received: by mail-qk1-x72d.google.com with SMTP id 21so23144699qky.4 for ; Fri, 17 Jan 2020 07:54:10 -0800 (PST) In-Reply-To: <20200116190644.uytvzvypuvdwh2iq@n0> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: ison Cc: Guix Devel On Thu, 16 Jan 2020 at 20:06, ison 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-' where 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-'? 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