netcdf orphaned; Fortran integration

[Kevin Ballard]

On Jan 12, 2007, at 12:00 AM, Michael Sternberg wrote:

> The netcdf port seems orphaned:
>
> 	http://trac.macports.org/projects/macports/browser/trunk/dports/ 
> science/netcdf/Portfile
>
> As per  http://metadir.andrew.cmu.edu/mailsearch.html  the previous  
> maintainer is no longer affiliated with CMU.  I'll see if I can  
> follow up more tomorrow.
>
>
> The reason I'm asking is because I need the fortran interface for a  
> user's code, and perhaps later plug in more recent versions.  I  
> managed to locally add a variant "+ifort" using "port edit", which  
> relies on the Intel Fortran compiler, and the package's regression  
> test "make test" passes, explicitly verifying the fortran interface  
> as well.

Great. Perhaps you'd like to become the maintainer of the port?

> Now for the bleeding newbie questions:
>
>
> Q1: Is it OK to use a commercial compiler?

I have no idea if there's a general policy on that. By use do you  
mean the compiler's used to install the port, or the installed port  
utilizes the compiler? If it's the former, I'd say try and use an  
open-source compiler for which a Portfile exists (gcc41 includes  
fortran95 support, for example). If it's the latter, it's probably ok  
but someone else really should chime in here.

> Q2: What's the canonical way to express that?
> 	- note dependency (if any)?
> 	- note compiler version?  (ifc7, ifc8, and ifort9 are notably  
> different)

If you depend on a compiler for which the Portfile exists, declare  
the dependency like you see other ports doing. If you require a  
commercial compiler to install the port, well, I don't know what you  
should do. Offhand I'd say note such in the long_description. Perhaps  
if this is something that's necessary we could add, for example, a  
variant on the bin: style of dependency which takes just a binary  
name (i.e. no port name), and if the binary isn't found it errors out?

If your port doesn't require the compiler to build, and functions  
normally if the compiler is not present (but utilizes the compiler if  
it is), I'd say just note that in long_description. Of course, this  
is only if the compiler has no Portfile (which a commercial one  
wouldn't). Again, if there is a Portfile, you should do a depends_run  
on it.

> Q3: Where do I submit a patch to a non-maintainer?  If I go to:
>
> 	http://trac.macports.org/projects/macports/report
>
>     and click on the big "New Ticket" (not obvious as a link, BTW),  
> I get:
>
> 	http://trac.macports.org/projects/macports/newticket
> 	Permission Denied
>
> 	TICKET_CREATE privileges are required to perform this operation

You should be able to register for an account. Look in the upper- 
right corner of the page. I've heard of people saying they still  
can't create tickets after registering, but hopefully that's been  
fixed. If not, simply speak up and a Trac maintainer should be able  
to give you appropriate privileges.

> Has the dust settled since the DarwinPorts migration?  Seems some  
> of the docs are not yet migrated.

Not entirely.

> Any help appreciated - I mean, I'd like to push my patch upstream,  
> so I get the benefit on other hosts without creating my own patch  
> management system ;-)

Glad to see you taking a hand in keeping the ports updated.

-Kevin Ballard

-- 
Kevin Ballard
http://kevin.sb.org
eridius at macports.org
http://www.tildesoft.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20070112/f22ed617/attachment.html