dependency options in portfiles
Glen Whitney
gwhitney at pobox.com
Fri May 4 19:19:47 PDT 2007
Dear MacPorts folks,
Portfiles currently have three dependency options:
depends_build, depends_run, and depends_lib.
However, the correspondence between these options and the processing
phases (I guess "targets" in the internal terminology of the MacPorts
base code) is weak: depends_build does record the dependencies that are
necessary for the build target, but there is no run target or lib
target, rather the following rich collection of targets:
main, unarchive, fetch, checksum, extract, patch, configure, build,
test, destroot, archive, install, activate (and port understands the
relationship among these with the requires/provides attributes of the
targets).
Currently, depends_run corresponds to the destroot phase (but
conceptually it seems like it should either correspond to test or
activate, from the name) and depends_lib corresponds to configure.
In any case, it's clearly natural to classify dependencies by the
phase at which they kick in; and conversely, various other of the above
phases could quite reasonably have dependencies specific to them. For
example, if a package is released with a spiffy new compression
algorithm which is not yet universally available, the extract step for
that package could depend on the port of the decompressor for that
algorithm. Or the real backstory here: I'm trying to create Portfiles
which capture the current gtk+osx build process, which I have gotten to
work manually all the way up to Gnucash, but which I never want to have
to do by hand again. Currently one needs to extract the cairo
development head by git for this all to work. I would therefore like the
fetch phase to depend on the git port, but currently there's no way to
specify any dependency for fetch.
So the following proposal seems like it would be a big win to me.
Each target should have an optional depends attribute, i.e.
configure.depends port:libiconv #typical case now
or
fetch.depends port:git_core #my case
or
activate.depends port:ghostview #e.g., previewer is never used until
active pkg is invoked by user, but this is our Last Chance
Before MacPorts executes any target, it would ensure that all of the
dependencies for that target (and the targets it requires, i.e. the
earlier build phases) are activated.
From looking at the code, there are a number of places where the list
of targets is reiterated in order to figure out whether to compute
dependencies, which depends options to look at, etc. It seems to me that
this change would actually end up simplifying the code noticeably and
remove a number of these anti-modular lists of targets in the code,
easing any potential addition of future targets.
Of course, for backwards compatibility, depends_lib, depends_build,
and depends_run would remain as (deprecated) aliases of
configure.depends, build.depends, and destroot.depends. (How do I
implement that aliasing? I'm not experienced with Tcl.)
What do people think? I'm happy to write and submit a patch to make
this change if the new functionality stands a high likelihood of being
accepted. From reading the code, and writing the patch for a -y "dry
run" option (submitted to ticket #11892, which may be of independent
interest), I do not think that it will be that hard.
Thanks for your thoughts,
Glen
More information about the macports-dev
mailing list