[gentoo-science] Gentoo Science next meeting agenda - 5) fortran

[gentoo-science] Gentoo Science next meeting agenda - 5) fortran

[Kacper Kowalik]

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

Again, for the reference and starting point for the discussion
Donnie's blog post:
http://bit.ly/dLwdFe

Additionally we should think about what compilers we're gonna support
(in term of b.g.o). I would like to stick to Intel and GFortran.
I have access to PGI, Pathscale and SunStudio but they were always a
PITA to use for me, so I would like to avoid them if possible...
Cheers,
Kacper



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

Re: [gentoo-science] Gentoo Science next meeting agenda - 5) fortran

[George Shapovalov]

Looks like due to google remapping email headers and some changes in gentoo 
infra my reply did not get to the list. So, here it goes again, now avoiding 
gmail :).
BTW, there were a few posts on this topic in the linked thread on Donnie's 
blog since my last post attempt.

On Sunday 05 December 2010 13:55:40 Kacper Kowalik wrote:
> Again, for the reference and starting point for the discussion
> Donnie's blog post:
> http://bit.ly/dLwdFe
Very interesting - that this point started coming up in multiple places 
lately. I guess "the time has come" finally.  

My interest/"involvement" here is that Ada has been implementing such a system 
for many years now (perhaps the first such miltiABI class in the tree), 
therefore, if there some technical issues that can be referenced:
http://www.gentoo.org/proj/en/prog_lang/ada/dev_reference.xml
(unfortunately incomplete, but I should have put principal points there before 
"dropping it") and discussed.

The implementattion is somewhat along the lines of "2." point in thatDonnie's 
post. In fact, 2 and 3 follow the same principle, the difference is only where 
the multi-build control code resides - in the ebuild or external script. The 
Ada implementation places it in the "standard" locations: an eclass for 
building compilers, an eclass for taking care of libs and eselect module "to 
rule them all". There is even an option of selecting "primary" profiles - the 
ones for which libs will be built, and having "experimental" - just for play 
compilers. Therefore I would suggest to interested people to look at the 
code/contact me, etc.. I think we can all benefit from discussing this topic. 

Overal though, I would very much like to push for the standard "in portage" 
treatment of multiple ABIs - at leas for PM providing some necessary 
"core"functionality. However this is still not out of the design phase, as I 
understand..

George

Re: [gentoo-science] Gentoo Science next meeting agenda - 5) fortran

[justin]

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

Hi all,

my removal of the fortran.eclass has left many packages in a broken
state. Many packages and/or their buildsystem depend on
(x86_64|i686)-linux-gnu-gfortran being simple named gfortran. For
example the cns package uses the Makefile.gfortran, which was formerly
Makefile.${FORTRANC}, but now a Makefile.$(tc-getFC) doesn't work. Same
for Makefile.ifort vs Makefile.ifc. Similar happasn to many packages and
excuse me to have some problems today. Iwill fix that.

So my proposal is to create a fortran-ng.eclass which gives us simply
the a variable similar to FORTRANC representing the old style naming, so
that not every ebuild has to implement it again.

case $(tc-getFC) in
   *gfortran* )
      FCOMP="gfortran" ;;
   ifort )
      FCOMP="ifc" ;;
   * )
      FCOMP=$(tc-getFC) ;;
esac


justin


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

Re: [gentoo-science] Gentoo Science next meeting agenda - 5) fortran

[Donnie Berkholz]

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

On 08:46 Fri 17 Dec     , justin wrote:
> Hi all,
> 
> my removal of the fortran.eclass has left many packages in a broken
> state. Many packages and/or their buildsystem depend on
> (x86_64|i686)-linux-gnu-gfortran being simple named gfortran. For
> example the cns package uses the Makefile.gfortran, which was formerly
> Makefile.${FORTRANC}, but now a Makefile.$(tc-getFC) doesn't work. Same
> for Makefile.ifort vs Makefile.ifc. Similar happasn to many packages and
> excuse me to have some problems today. Iwill fix that.
> 
> So my proposal is to create a fortran-ng.eclass which gives us simply
> the a variable similar to FORTRANC representing the old style naming, so
> that not every ebuild has to implement it again.
> 
> case $(tc-getFC) in
>    *gfortran* )
>       FCOMP="gfortran" ;;
>    ifort )
>       FCOMP="ifc" ;;
>    * )
>       FCOMP=$(tc-getFC) ;;
> esac

I wonder if this would instead merit a small separate function in 
toolchain-funcs.

-- 
Thanks,
Donnie

Donnie Berkholz
Sr. Developer, Science Team
Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]