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
participants (1)
-
Glen Whitney