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
short/medium/forever term?
Pros:
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.
Cons:
Adds complexity, namespace bloat.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
