On 2016-6-1 03:34 , Mojca Miklavec wrote:
On 27 March 2016 at 17:33, Rainer Müller wrote:
On 2016-03-27 16:57, René J.V. Bertin wrote:
Can someone please summarise the exact priority rules used in
resolving the file to be included when using a PortGroup statement in
a port?
1. _resources/port1.0/group/*.tcl in ports tree of this port
2. _resources/port1.0/group/*.tcl in default ports tree
This is here in the base source:
proc PortGroup:
https://trac.macports.org/browser/trunk/base/src/port1.0/portutil.tcl?rev=147064#L2561
porc getportresourcepath/getdefaultportresourcepath:
https://trac.macports.org/browser/trunk/base/src/macports1.0/macports.tcl?rev=147103#L1637
The _resource directory is meant to contain files that are specific to
this ports tree. This allows local modifications to port groups in a
ports tree without influencing other ports trees.
Can you please explain if the following behaviour is intended by
design or if it is a bug?
"port something portname" works like you describe
"port something ./[path/to/]portname" uses the default portgroup
A concrete example. I modified livecheck in the perl5 PortGroup in the
local svn checkout. Then I tested the following:
$ cd /path/to/local/checkout
$ portindex
$ port -d livecheck perl/p5-b-c # uses *global* resources
$ port -d livecheck perl/p5-* # uses *global* resources
$ cd perl
$ port -d livecheck p5-b-c # uses local resources
$ port -d livecheck p5-* # uses local resources
$ port -d livecheck ./p5-b-c # uses *global* resources
$ cd p5-b-c
$ port -d livecheck ./ # uses local resources
$ port -d livecheck # uses local resources
These examples seem somewhat strange to me.
It's more like a limitation of the information that is available when
you parse an arbitrary Portfile, whether implicitly using the current
directory or specifying a path. You don't even know the port's name
until you parse it once. If you're not going via the PortIndex, you
don't know what repo (if any) it belongs to and thus whether it has any
local resources. So the default ones get used.
I guess with enough effort you could figure out when some arbitrary path
is inside a sources.conf repo, but is it worth it when you can easily
fix the problem by looking up via the index?
Cf. also <https://trac.macports.org/ticket/15186> which is sort of the
opposite problem.
- Josh
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
