gfortran standalone port

[Sean Farley]

On Thu, Jan 17, 2013 at 4:54 PM, Jeremy Huddleston Sequoia
<jeremyhu at macports.org> wrote:
>
> On Jan 17, 2013, at 14:44, Joshua Root <jmr at macports.org> wrote:
>
>> On 2013-1-18 08:09 , Jeremy Huddleston Sequoia wrote:
>>>
>>> It would be nice if 'port lint' would report about missing license lines in dependencies as well.  Maybe 'port lint -R' could be made to do this.
>>
>> I'm not sure linting all the dependencies is really what you're after
>> here. You can check for dependencies without licenses with:
>>
>> port echo rdepof:myport and license:unknown
>>
>> Would doing this in the post-commit hook be useful or just annoying?
>>
>> As an aside, consider that there are 151 active committers listed. If
>> they each set the license on one port a day, all 4895 remaining ports
>> would have a license after 33 days.
>
> That would be useful.  The message could state, "This port will not be prepared as a binary package because the following ports do not have known licenses:
> …"

I didn't mean to derail this thread with an offhanded comment about
the binary package, sorry. Regardless of having a binary package or
not, we still have a problem with dependencies:

$ port install mpich -> no fortran enabled

$ port install mpich +gcc45 -> fortran enabled

This, again, relates to ticket 126 and not having a way to query
variants. The active-variant port group doesn't really help because
many variants (any +gcc4X) would satisfy the fortran need. A decent
workaround is to "close" all ports that have no fortran enabled
without +gcc4X and to provide both g95 and gfortran for these ports.
So, we could have:

$ port install mpich -> fortran enabled with gfortran, clang for other compiler
$ port install mpich +g95 -> fortran enabled with g95, clang again
$ port install mpich +gcc45 -> fortran enabled obviously

That is to say, for mpi and other such ports that have a fortran need
(SuiteSpare, py-scipy, etc.), to always have a fortran compiler
available.