On 6/15/11 9:13 AM, Steven Schveighoffer wrote:
On Wed, 15 Jun 2011 09:53:31 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 6/15/11 7:53 AM, Steven Schveighoffer wrote:
On Tue, 14 Jun 2011 16:47:01 -0400, Adam D. Ruppe
<[email protected]> wrote:
BTW, I don't think it should be limited to just passing a
url to the helper program.
I'd do it something like this:
dget module.name url_from_pragma
I still don't like the url being stored in the source file -- where
*specifically* on the network to get the file has nothing to do with
compiling the code, and fixing a path problem shouldn't involve editing
a source file -- there is too much risk.
First, clearly we need command-line equivalents for the pragmas. They
can be subsequently loaded from a config file. The embedded URLs are
for people who want to distribute libraries without requiring their
users to change their config files. I think that simplifies matters
for many. Again - the ULTIMATE place where dependencies exist is in
the source files.
We have been getting along swimmingly without pragmas for adding local
include paths. Why do we need to add them using pragmas for network
include paths?
That doesn't mean the situation is beyond improvement. If I had my way
I'd add pragma(liburl) AND pragma(libpath).
Also, I don't see the major difference in someone who's making a piece
of software from adding the include path to their source file vs. adding
it to their build script.
Because in the former case the whole need for a build script may be
obviated. That's where I'm trying to be.
But in any case, it doesn't matter if both options are available -- it
doesn't hurt to have a pragma option as long as a config option is
available. I just don't want to *require* the pragma solution.
Sounds good. I actually had the same notion, just forgot to mention it
in the dip (fixed).
For comparison, you don't have to specify a full path to the compiler of
where to get modules, they are specified relative to the configured
include paths. I think this model works well, and we should be able to
re-use it for this purpose also. You could even just use urls as include
paths:
-Ihttp://www.dsource.org/projects/dcollections/import
I also think that model works well, except HTTP does not offer search
the same way a filesystem does. You could do that with FTP though.
dget would just add the appropriate path:
import dcollections.TreeMap =>
get
http://www.dsource.org/projects/dcollections/import/dcollections/TreeMap.d
hm.. doesn't work
get
http://www.dsource.org/projects/dcollections/import/dcollections/TreeMap.di
ok, there it is!
This assumes the URL contains the package prefix. That would work, but
imposes too much on the URL structure. I find the notation -Upackage=url
more general.
As I said in another post, you could also specify a zip file or tarball
as a base path, and the whole package is downloaded instead. We may need
some sort of manifest instead in order to verify the import will be
found instead of downloading the entire package to find out.
Sounds cool.
Andrei
