unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: "Paul A. Patience" <paul@apatience.com>, Guix Devel <guix-devel@gnu.org>
Subject: Re: Adding Trilinos to dealii package
Date: Sun, 23 May 2021 14:40:04 +0200	[thread overview]
Message-ID: <867djpy66z.fsf@gmail.com> (raw)
In-Reply-To: 8iXokLJz8g9vAHrX2pFDjHgz8tYMLRM4CNZwiOx2nQXIf6gO7B0PQGFigeTmf-vFzIIZi7Io4YSBkQezgQ7BsToDVkT2jeoqFVSMvJuX9kI=@apatience.com

Hi,

> PETSc and Trilinos (and many other libraries available in Guix) can be
> compiled with several different options.
> What is the standard way to deal with this in Guix?

AFAIK, there is no concrete standard way.  Only what explained Arun. ;-) 

> The potential problem with PETSc and Trilinos when it comes to dealii is
> that some of the optional modules they can be compiled with are the
> same, which causes trouble when dealii is configured with both of
> them [2].
> (From what I can tell, the module in question is not configured in the
> Guix package for PETSc, so this point may be moot.)

What I miss is: Trilinos is somehow a replacement of PETSc.  You would
like Deal.II compiled with both Trilinos *and* PETSc support, right?

> I'm wondering what the best way would be to add Trilinos to the dealii
> packages (assuming I manage to package Trilinos as well).

FWIW, I would start by package Trilinos. ;-)

> - Some other possibility I have not thought of.

IIUC, your question is how Guix deals with “package parameters“, right?
And the answer is: it is complicated. ;-)

First, I do not know if it is worth to have many variants in Guix
proper.  There is 2 things to consider: a) how complicated the recipe of
the variant is?  and b) how much resource (CPU, RAM, etc.) does the
variant require to be built?  Somehow, if the recipe is simple enough,
by simply apply package transformation (say), and if it can be built on
a powerless laptop (say), then the variant does not worth, IMHO.  Else,
it is an open discussion. ;-)

Second, I would like to mention the guix-science@gnu.org mailing list
where this kind of questions are sometimes discussed.  And
hpc.guix.info/about lists scientific channels where the workload could
be shared.

Hope that helps,
simon


             reply	other threads:[~2021-05-23 12:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-23 12:40 zimoun [this message]
2021-05-24 17:04 ` Adding Trilinos to dealii package Leo Famulari
  -- strict thread matches above, loose matches on Subject: below --
2021-05-24 17:53 Paul Garlick
2021-05-21 12:36 Paul A. Patience
2021-05-23  5:19 ` Arun Isaac

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

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=867djpy66z.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=paul@apatience.com \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).