On Mar 3, 2011, at 6:26 PM, Ryan Schmidt wrote:
>
> How, in your new proposal, would someone indicate that a binary anywhere in
> bin_path should be acceptable? (what bin:-style currently does)
path:foo
would search for foo in binpath
> How would someone indicate that only a particular file in ${prefix} is
> acceptable? (what path:-style currently does)
path:${prefix}/foo
any absolute path would just check for that exact file
> What would it be possible to specify in your new dependency style that we
> can't already accomplish with what we have today?
Port A depends on specific library B (and not just on the port that provides
B). Or port A depends on specific binary Q (and not just on the port that
provides Q).
>>> I would rather educate port authors as to how to use them the way they work
>>> today, and improve the documentation if needed.
>>
>> There's basically no documentation (the guide doesn't mention it, and the
>> Portfile man page doesn't either).
>
> It is documented in the guide; the wording and arrangement could possible be
> improved:
>
> http://trac.macports.org/browser/trunk/doc-new/guide/xml/portfile-dependencies.xml#L109
>
> Also, that section does not appear on the guide web site:
>
> http://guide.macports.org/
... which means it's not really in the guide (at least right now).
> In its place, there appears just "<xi:include></xi:include>" (scroll up just
> a little from http://guide.macports.org/#reference.variants to see that). I
> do not know why. It used to show up fine. Maybe there is a syntax error in
> the XML somewhere, or maybe the guide just needs to be regenerated.
Good to know it's probably just something simple that can be fixed.
> If we go changing the way things work again, we're bound to introduce new
> bugs, just when everything is actually working as designed, so let's not.
Ok, so we're in permanent code freeze? Everything is perfect now. ;-)
> Also, coordinating changes in base with changes in portfiles is a hassle
> since we don't have a way to ensure that users upgrade base at any particular
> time. Users often sync to get new portfiles, and don't necessarily selfupdate
> to get new base as often. It's bad enough when we add a new feature to base
> and then want to use that new feature in portfiles; we have to wait weeks
> after the release before we touch the portfiles to increase the likelihood
> that most users will have upgraded base by then, and even so we still get
> reports from those who haven't. It would be a nightmare if we *changed* how
> *existing* functionality behaves.
So we need to implement some better handing for that kind of upgrade, then,
right?
We could implement the same idea without re-using the existing lib/bin/path
stuff, too (if that would make it easier). The more-specific dependency types
would just be new names.
... or if we automate link checking, then I don't really care (we can discover
any library/link dependencies and record them - any other dependency would be a
'file' dependency [header, executable, or other data]).
--
Daniel J. Luke
+========================================================+
| *---------------- [email protected] ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
