Please review: proposed dependency handling change
Jordan K. Hubbard
jkh at apple.com
Mon May 5 20:09:40 PDT 2008
On May 5, 2008, at 5:59 PM, Joshua Root wrote:
> The full enhancement requested by the ticket will (AFAICT) be rather
> difficult to implement at present. I have however attached a patch
> which improves things a bit. It makes 3 things better:
> 1. You can use depends_build for software that needs to be used in
> the extract or patch phases. This helps e.g. python23 which needs
> gnutar for extract.
> 2. You can use depends_build for software that is needed for the
> configure phase but not at runtime (e.g. pkgconfig). Currently
> depends_build is not checked until after the configure phase.
> 3. Dependencies weren't being checked when running some packaging
> targets. Now they are.
This raises an important question:
Is there any value in creating depends_foo procs for each reasonable
value of foo, even if they are just aliases for depends_build in the
There is some documentary value to being able to say depends_extract
<blah> or depends_configure <feh> even if they just fold to
depends_build since it's clearer from the declaration just why the
dependency is needed.
At some point, there might be real value to distinguishing between
the types of dependencies. Say you were going on a business trip and
looked forward to having plenty of spare CPU/disk cycles to build
stuff on your laptop but not such great internet connectivity. You
might do "port fetch bar" and expect it to only pre-populate your
distfile cache, plus any tools the dependencies for bar might need
just for fetching, but not actually build anything.
Might be less confusing than trying to explain that there are really
only two umbrella dependencies types even though there are lots of
different possible targets.
Adds complexity, namespace bloat.
More information about the macports-dev