Hello folks, 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. Now for the bleeding newbie questions: Q1: Is it OK to use a commercial compiler? Q2: What's the canonical way to express that? - note dependency (if any)? - note compiler version? (ifc7, ifc8, and ifort9 are notably different) 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 Has the dust settled since the DarwinPorts migration? Seems some of the docs are not yet migrated. 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 ;-) Regards, Michael
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@macports.org http://www.tildesoft.com
Hello Kevin, On Jan 12, 2007, at 10:13 , Kevin Ballard wrote:
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 Great. Perhaps you'd like to become the maintainer of the port?
After some hesitation, I decided I might as well, and get some practice.
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.
Nothing yet. But, I noticed a gfortran dependency in the FFTW lib (which I also looked at, but it's very obtuse to build with ifort due to compiler-specific C-Fortran interface hackery). Regards, Michael
Hello, I'm testing to set a fortran dependency for port netCDF (this is a library which may be built with an optional fortran interface). I have difficulty convincing port(1) to find the fortran compiler in $PATH. Trying to use a commercial compiler (intel fortran), I source its dotfiles interactively (to augment $PATH etc.), then run: port -dk install netcdf +ifort This fails because "configure" when run under port claims it cannot find the fortran compiler. However, when I run the exact same command manually (as root), it succeeds (diff attached). Does port(1) clean out $PATH ?? brahms:/opt/local root# port --version MacPorts 1.400 [Really? I pulled the svn src version for port and the dports tree because I cannot get rsync updates through a firewall. Did I shoot myself in the foot?] Regards, Michael
On Jan 29, 2007, at 12:24, Michael Sternberg wrote:
I'm testing to set a fortran dependency for port netCDF (this is a library which may be built with an optional fortran interface). I have difficulty convincing port(1) to find the fortran compiler in $PATH.
Trying to use a commercial compiler (intel fortran), I source its dotfiles interactively (to augment $PATH etc.), then run:
port -dk install netcdf +ifort
This fails because "configure" when run under port claims it cannot find the fortran compiler. However, when I run the exact same command manually (as root), it succeeds (diff attached).
Does port(1) clean out $PATH ??
I don't know about any of that.
brahms:/opt/local root# port --version MacPorts 1.400
[Really? I pulled the svn src version for port and the dports tree because I cannot get rsync updates through a firewall. Did I shoot myself in the foot?]
1.320 is the most recent released version of MacPorts. There's no need to check out and build the source code for the entire MacPorts trunk from Subversion just to avoid rsync updates. Just install MacPorts normally by downloading the DarwinPorts-1.3.1 disk image. Then edit /opt/local/etc/ports/sources.conf. Comment out (put a "#" in front of) the line "rsync://rsync.darwinports.org/dpupdate/dports" and add a line pointing to a place on your hard drive where you will check out the port tree with Subversion. For example, on my system, I added the line "file:///Users/rschmidt/dports". To check this out initially, I typed "svn checkout http://svn.macosforge.org/repository/ macports/trunk/dports ~/dports". Now, to update it, instead of "sudo port sync", I use "svn up ~/dports". To update to 1.3.2 (a.k.a. 1.320) you would need to do a "sudo port selfupdate" and admittedly I'm not sure if that also requires rsync. If it does, then that's of course a problem again. You could also have downloaded and built the 1.3.2 source code from http://svn.macosforge.org/repository/macports/downloads/ DarwinPorts-1.3.2/ or http://svn.macosforge.org/repository/macports/ tags/release_1_3_2/base/ and then configured sources.conf as detailed above.
On Jan 29, 2007, at 1:24 PM, Michael Sternberg wrote:
I'm testing to set a fortran dependency for port netCDF (this is a library which may be built with an optional fortran interface). I have difficulty convincing port(1) to find the fortran compiler in $PATH.
Trying to use a commercial compiler (intel fortran), I source its dotfiles interactively (to augment $PATH etc.), then run:
port -dk install netcdf +ifort
This fails because "configure" when run under port claims it cannot find the fortran compiler. However, when I run the exact same command manually (as root), it succeeds (diff attached).
Does port(1) clean out $PATH ??
If you look at /opt/local/etc/ports/ports.conf, at the bottom is a list of environment variables to keep. You may want to try setting that to PATH. -- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
On Jan 29, 2007, at 5:41 PM, Kevin Ballard wrote:
Does port(1) clean out $PATH ??
yes.
If you look at /opt/local/etc/ports/ports.conf, at the bottom is a list of environment variables to keep. You may want to try setting that to PATH.
That won't work. macports' PATH is set to "${prefix}/bin:${prefix}/sbin:/bin:/sbin:/ usr/bin:/usr/sbin:/usr/X11R6/bin" unless 'binpath' is set in the ports.conf file. (see darwinports1.0/darwinports.tcl line 415 and darwinports1.0/ portconf.c line 49) -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
Ah. Well, since port allows you to override specific variables using a variable=value syntax at the end of the command line, you could try setting bindir yourself there. On Jan 29, 2007, at 5:52 PM, Daniel J. Luke wrote:
On Jan 29, 2007, at 5:41 PM, Kevin Ballard wrote:
Does port(1) clean out $PATH ??
yes.
If you look at /opt/local/etc/ports/ports.conf, at the bottom is a list of environment variables to keep. You may want to try setting that to PATH.
That won't work.
macports' PATH is set to "${prefix}/bin:${prefix}/sbin:/bin:/sbin:/ usr/bin:/usr/sbin:/usr/X11R6/bin" unless 'binpath' is set in the ports.conf file.
(see darwinports1.0/darwinports.tcl line 415 and darwinports1.0/ portconf.c line 49)
-- Kevin Ballard http://kevin.sb.org eridius@macports.org http://www.tildesoft.com
Having an internally consistent PATH file is one of the things that makes MacPorts as stable as it is. If your port is for your own consumption, you might use binpath. If your port is for public use, but doesn't require the commercial compiler you're using, then you probably shouldn't change the binpath unless you put it in a variant. If you need a really strange environment (i.e., one in which a file has been sourced), you might make a wrapper to do the build progress that first calls the file to be sourced and then runs make or configure or whatever. Remember that the environment for build is different from the environment or configure, so you'll have to source the file twice if configure doesn't set everything. -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University On Mon, 29 Jan 2007, Daniel J. Luke wrote: o On Jan 29, 2007, at 5:41 PM, Kevin Ballard wrote: o > > Does port(1) clean out $PATH ?? o o yes. o o > If you look at /opt/local/etc/ports/ports.conf, at the bottom is a list of o > environment variables to keep. You may want to try setting that to PATH. o o That won't work. o o macports' PATH is set to o "${prefix}/bin:${prefix}/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin" o unless 'binpath' is set in the ports.conf file. o o (see darwinports1.0/darwinports.tcl line 415 and darwinports1.0/portconf.c o line 49) o o -- o Daniel J. Luke o +========================================================+ o | *---------------- dluke@geeklair.net ----------------* | o | *-------------- http://www.geeklair.net -------------* | o +========================================================+ o | Opinions expressed are mine and do not necessarily | o | reflect the opinions of my employer. | o +========================================================+ o o
participants (5)
-
Daniel J. Luke
-
Kevin Ballard
-
Michael Sternberg
-
Ryan Schmidt
-
Salvatore Domenick Desiano