Le 17 avr. 2014 à 19:16, Sean Farley <s...@macports.org> a écrit : > Sébastien Maret <sebastien.ma...@icloud.com> writes: > >> Le 17 avr. 2014 à 18:13, Sean Farley <s...@macports.org> a écrit : >> >>> Sébastien Maret <sebastien.ma...@icloud.com> writes: >>> >>>> Le 17 avr. 2014 à 01:19, Sean Farley <s...@macports.org> a écrit : >>>> >>>>> Sébastien Maret <sebastien.ma...@icloud.com> writes: >>>>> >>>>>> Le 27 mars 2014 à 22:03, Ryan Schmidt <ryandes...@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’).
If i put cxx in compilers.choose (or leave compilers.choose blank) and install the +gcc48 variant the package, it uses g++-mp-4.8 to compile the C++ part of the code. This is not what I want. I need the C++ code to be compiled with clang++ (as advised by Ryan), and the rest with GCC4.8. Setting compilers.choose to "cc cpp fc » does this. By the way: this compiling C++ with anything other than clang is not recommended, shouldn’t compilers 1.0 enforce that rule and set compiler.cxx to clang++ by default? > 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. I didn’t know that. Yet clang does not compile Fortran, and it shows up in the variants even when require_fortran is set. But I guess it is the port file developer responsibility to blacklist compiler than can’t compile his port. >>> - 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. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev