[gentoo-science] Fwd: [gentoo-dev] About maintaining sci-physics/abinit

[gentoo-science] Fwd: [gentoo-dev] About maintaining sci-physics/abinit

[justin]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

Hi,

is anybody willed to maintain abinit?

I will help and guide you if needed.


Thanks justin


-------- Original Message --------
Subject: [gentoo-dev] About maintaining sci-physics/abinit
Date: Mon, 19 Mar 2012 10:22:23 +0100
From: Pacho Ramos <pacho@gentoo.org>
Reply-To: gentoo-dev@lists.gentoo.org
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
CC: dberkholz@gentoo.org, sci@gentoo.org, sci-physics@gentoo.org

Hello

As talked some time ago with Donnie, sci-physics/abinit is hard to
maintain and, then, he would like to lastrite it after moving package to
sci overlay because looks like nobody from sci team wants to take it.

If anybody is willing to help with maintaining abinit, could he take it?
If not, could anybody with commit access to sci overlay to move abinit
to it and let us lastrite it from main tree?

Thanks a lot



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-science] Fwd: [gentoo-dev] About maintaining sci-physics/abinit

[Honza Macháček]

[-- Attachment #1: Type: text/plain, Size: 4278 bytes --]

On 03/19/2012 02:48 PM, justin wrote:
> Hi,
>
> is anybody willed to maintain abinit?
>
> I will help and guide you if needed.
>
>
> Thanks justin

Well, I am sort of maintaining it for myself, committing to the overlay. But
this is about the main tree, with respect to the plan of leaving Abinit in the
overlay only, isn't it?

At present, I am taking particularly long time with 6.12.1, since the upstream
developers took finally a big leap forward with the version of BigDFT they use,
some old stuff to compile Abinit with external BigDFT stopped working (the
libraries are organised somewhat differently), and I would like to go directly
to the latest version (1.6.0, has started using pkg-config) instead of the
second latest (1.6-tuto).

I have cleaned up the mess after your improvements to the BigDFT ebuild, but I
am postponing my commit of it until I have the new Abinit compiled with its use
(my old abinit ebuilds, by the way, are broken by your removal of the old BigDFT
versions). BigDFT has changed from 1.6-tuto to 1.6.0 more than I have expected,
so I may have to try and actually understand a bit some of its routines that
Abinit calls.

On my way to the new ebuilds I am contemplating the case of libabinit. Abinit by
default does not install it, it even does not offer that as a configure option,
only its main Makefile allows creating the library. As far as I have found, it
does not use it, the library is just a package of some stuff, internal
otherwise, that might be of interest to other projects, like BigDFT. So if we
install libabinit separately by its own ebuild, Abinit itself will ignore it.
Abinit uses (optionally) the libraries of BigDFT (and I am not sure if libabinit
depends on them, if selected, or not); the in-tree ebuild (I've forgotten it
even exists) just allows Abinit to download BigDFT (as well as several other
plug-ins) during compilation(!) and compile its own copies of its own selected
versions, my ebuild uses all the options as external libraries.  BigDFT uses
libabinit, and I have not yet tried to set it up against an external copy;
actually I have not yet even installed such a copy from the Abinit sources, I am
just studying the way to do so. Since the 1.6-tuto version (well, maybe even
before, but Abinit has not, until recently, used anything beyond 1.2.x, and last
time I tried patching it for 1.3.x or newer, I failed miserably) BigDFT not only
compiles its own libabinit from its own selection of the Abinit sources
(possibly modified, I have not looked into this), but even installs it. Thus
Abinit using BigDFT will have to link against libbigdft along with libabinit,
provided by BigDFT; if I manage to install libabinit from the Abinit package, as
well as to compile BigDFT against it, there will at least be a circular dependency.

Maybe the best solution would be to compile BigDFT inside Abinit, after all.
Does anyone use BigDFT on its own? I am currently thinking of that but I do not
plan to stop using Abinit, and as far as I know, nobody has yet complained of
BigDFT being sci-libs/bigdft instead of sci-physics/bigdft.

Sorry for too long a comment. I am afraid I have missed the right way of
discussing overlay ebuilds. So I am silently committing my ebuilds from time to
time, and cursing loudly (in a discreet seclusion) those who contribute to the
same ebuilds, often breaking my stuff.

With best regards

Honza Macháček

P. S. Only when I started my first calculations with BigDFT, and it occured to
me I could possibly view their results in v_sim, I noticed there already is
sci-visualization/v_sim ebuild thanks to Jérôme Borme, Andreas K. Huettel,
yourself, and Dongxu Li, the last Changelog entry by Dongxu Li complaining of
the Abinit installation. Just then I realised that Abinit, left to its own
devices, install completely bogus pkg-config file, and does not even install the
libraries (different from libabinit) that it advertises there. I am working on
that currently (looks easy, I hope) but I wonder: Is the roundabout way I have
got known there is this work to do just my fault, just a symptom of my moderate
psychopathy, or is it a symptom of some communication deficiency syndrome of the
overlay?


[-- Attachment #2: Type: text/html, Size: 4982 bytes --]