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
[EMAIL PROTECTED]
http://www.tildesoft.com
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-users
