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