Compiler variants in portfile

David Strubbe dstrubbe at mit.edu
Thu Apr 17 10:33:21 PDT 2014


You can use "clang -E" to preprocess Fortran in a way compatible with gcc's
cpp (at least on the several codes I have tested it with).

David


On Thu, Apr 17, 2014 at 1:16 PM, Sean Farley <sean at macports.org> wrote:

>
> 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.
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140417/346e4216/attachment-0001.html>


More information about the macports-dev mailing list