On Wed, 15 Jun 2011 09:53:31 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 6/15/11 7:53 AM, Steven Schveighoffer wrote:
On Tue, 14 Jun 2011 16:47:01 -0400, Adam D. Ruppe
<destructiona...@gmail.com> 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?
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.
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.
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!
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.
-Steve
