Programmatically finding dependencies for a Portfile

[Rainer Müller]

On 2015-05-28 15:42, Artur Szostak wrote:
> How should this work without configuring sources.conf?
> I dont think I understand what you mean by port directory.

While the problem at hand was already solved with the other answer,
I still typed this as it might be useful for someone else stumbling
across this thread.

If you don't specify a portname, port(1) always looks for a Portfile in
the current directory. The directory does not need to be in a full ports
tree, just the single Portfile is enough. This is mainly meant for
development of new ports without the need to add them to a ports tree
and port index.

cd /tmp/testport
port deps
port info --depends
port info --depends_lib
...

Often, 'port -q' produces output which is better suited for screen scraping:

port -q info --depends_lib

All above would only list the direct dependencies of the port in the
current directory, 'port rdeps' would do it recursively opening other
Portfiles as found in the ports tress configured in sources.conf.

For most commands with a few exceptions, not specifying any port name is
equivalent to the explicit pseudo-port name "current". So the above
could also be written as:

port deps current
port info --depends current

If you want a specific subport, you need to specify the subport option.
This is only possible after a port name, so the 'current' is mandatory
in this case:

port deps current subport=testsubport
port info --depends current subport=testsubport

> Alternatively, where is the meat of 'port rdeps' implemented? I could try extract the code I need from there.

All port actions are implemented in src/port/port.tcl in base.
Extracting a single action out of this code might be possible, but the
parsing of port expressions and fetching the port information is in
generic procs used for all similar actions and the rest is mostly for
formatting of the output.

https://trac.macports.org/browser/trunk/base/src/port/port.tcl?rev=134986

I think what you showed in the port-tclsh snippet using mportopen before
was already better than going this route.

Rainer