Compiler variants in portfile

[Sean Farley]

Sébastien Maret <sebastien.maret at icloud.com> writes:

> Le 17 avr. 2014 à 18:13, Sean Farley <sean at macports.org> a écrit :
>
>> Sébastien Maret <sebastien.maret at icloud.com> writes:
>> 
>>> Le 17 avr. 2014 à 01:19, Sean Farley <sean at macports.org> a écrit :
>>> 
>>>> Sébastien Maret <sebastien.maret at icloud.com> writes:
>>>> 
>>>>> Le 27 mars 2014 à 22:03, Ryan Schmidt <ryandesign at macports.org> a écrit :
>>>>> 
>>>>>> On Mar 27, 2014, at 09:14, Sébastien Maret wrote:
>>>>>> 
>>>>>>> I’m writing a portfile for a software written in C/C++ and Fortran77/90:
>>>>>>> http://trac.macports.org/ticket/42886
>>>>>>> 
>>>>>>> Following a comment macsforever2000, I’ve modified my original port to provide several fortran compiler variants. However, my port requires that CC, CXX, CPP, and FC/F77 are all from a gcc variant. For example, it's not possible to compile it using CC=clang and FC=gfortran-mp-4.8. How can I modify it so that all compilers come from the same compiler suite?
>>>>>>> 
>>>>>>> Thanks in advance for your advices.
>>>>>> 
>>>>>> You do know that as of Mavericks, trying to compile C++ code with anything other than clang is a fool’s errand, right?
>>>>>> 
>>>>>> https://trac.macports.org/wiki/FAQ#libcpp
>>>>> 
>>>>> No, I didn’t know that.
>>>>> 
>>>>>> *Why* is it not possible to compile your software using CC=clang and FC=gfortran-mp-4.8?
>>>>> 
>>>>> I tried that but the compilation failed. I don’t exactly why but I’ll have a closer look. 
>>>> 
>>>> Sorry for the late reply, but it took me a while to catch up. Ryan is
>>>> right, of course. You should really figure out why they aren't compiling
>>>> and try to fix those errors.
>>> 
>>> Thanks for your answer.
>>> 
>>> I found the problem: the link was done against libstdc++ instead if libc++. I’ve fixed this and I’ve just posted a revised version of the port on the tracker.
>> 
>> Looking at the portfile, things seem mostly fine. A few comments (which
>> will hopefully help start documenting the compilers portgroup :-)
>> 
>> - compilers.choose is really meant to serve as a way to isolate a c-only
>>  or fortran-only build; since you specify both, you don't need it
>
> But isn’t this needed to set both CC, FC and CPP ? 

No, if you leave compilers.choose blank, then it will set all the compilers.

>> - removing the clang variants only stops macport's clang compilers from
>>  being used; this is fine but since you don't need c++ you could mix
>>  clang with gfortran
>
> Indeed I do need C++. And since a Fortran compiler is also needed, I would prefer to compiling Fortran and C with compilers from the same compiler suite (GCC) to avoid link problems. In addition the package requires CPP from GCC to compile properly (it is used in a non-standard way to pre-process Fortran code, and this does not work with Apple’s CPP).

If you need C++, then you forgot to mention it in compilers.choose
(missing 'cxx'). Also, "non-standard way to pre-process Fortran code"
... I didn't realize Fortran had a standard ;-P

> In fact I removed the clang variants because clang does not compile Fortran (same for drgaonegg). Why are variants present when require_fortran is set ? 

But dragonegg does compiler Fortran? That's mostly why it existed.

>> - what is it with IRAM, Labri, and Enseeiht not using autoconf? is
>>  everyone in France allergic to autotools?
>
> I’m not...  In fact, I would love them to use autotools. It would make the packaging a lot easier. I’ll forward your comment to them :-)

MUMPS and SCOTCH code development can only be measured on geological
timescales.