[MacPorts] #25562: miriad 4.1.3.20100512 - update to version 4.1.3.20100706
MacPorts
noreply at macports.org
Mon Jul 12 01:17:21 PDT 2010
#25562: miriad 4.1.3.20100512 - update to version 4.1.3.20100706
---------------------------------+------------------------------------------
Reporter: peter@… | Owner: macports-tickets@…
Type: update | Status: new
Priority: Normal | Milestone:
Component: ports | Version: 1.9.1
Keywords: haspatch maintainer | Port: miriad
---------------------------------+------------------------------------------
Comment(by peter@…):
Replying to [comment:5 ryandesign@…]:
> You're right, I find this controversial, and am not committing it yet.
You say this is meant to let the user use any compiler, yet you restrict
it to run ${prefix}/bin/gcc. This implies you're not letting the user run
any compiler installed anywhere after all; you're only letting them run a
compiler that can be selected with the MacPorts gcc_select tool. In that
case, why not just offer variants for each compiler MacPorts gcc_select
can select?
Because my intention was to have some special instructions for these power
users that had them write their own gcc_select data files in
${prefix}/etc/select/gcc that pointed to their special compilers.
This was the only solution I could come up with given the constraints that
1) users can only input information to the Portfile in binary form by
selection/deselection of variants 2) I don't know where the users will
install their fancy compilers or what names they'll have. The gcc_select
mechanism allows the port to be fed the locations of the fancy compilers
implicitly, by the symlinks it creates. We can't just say CC=cc and let
$PATH do the work, I think, because it doesn't seem like you can override
the $PATH used to build ports, which is an entirely reasonable thing if
that is indeed the case.
--
Ticket URL: <http://trac.macports.org/ticket/25562#comment:7>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list