On Wed, 15 Jun 2011 10:38:28 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 6/15/11 8:33 AM, Steven Schveighoffer wrote:
I can't really think of any other issues.
Allow me to repeat: the scheme as you mention it is unable to figure and
load dependent remote libraries for remote libraries. It's essentially a
flat scheme in which you know only the top remote library but nothing
about the rest.
The dip takes care of that by using transitivity and by relying on the
presence of dependency information exactly where it belongs - in the
dependent source files. Separating that information from source files
has two liabilities. First, it breaks the whole transitivity thing.
Second, it adds yet another itsy-bitsy pellet of metadata/config/whatevs
files that need to be minded. I just don't see the advantage of imposing
that.
Yes, these are good points. But I think Dmitry brought up good points too
(how do you specify that TreeMap.d needs to be compiled too?).
One possible solution is a central repository of code. So basically, you
can depend on other projects as long as they are sanely namespaced and
live under one include path.
I think dsource should provide something like this. For example:
http://www.dsource.org/import
then if you wanted dcollections.TreeMap, the import would be:
http://www.dsource.org/import/dcollections/TreeMap.d
Of course, that still doesn't solve Dmitry's problem. We need to think of
a way to do that too.
Still thinking....
-Steve
