I've implemented a prototype of the DIP11 draft.
http://www.wikiservice.at/d/wiki.cgi?LanguageDevel/DIPs/DIP11
https://github.com/dawgfoto/dmd/tree/DIP11

-- Restrictions --
 - It doesn't check for conflicting qualified imports (-Iacme=/path1 -Iacme.a=/path2)
 - pragma(importpath, "<import-path>") must come lexically before the import
 - Untested on Windows

-- Some outcome --
 - Using '=' in [module.or.package=]<path-or-url> could be slightly ambiguous for '-Ihttp://acme.org?format=raw'.
 - Url syntax collides with import path lists. Currently it is allowed to specify -I/path1/import:/path2/import for POSIX. I've deactivated that for now.

   Both can be disambiguated so they are not very severe.

 - Using 'pragma(lib, "someLib")' in an imported source has no effect, as long as the imported module is not compiled.
 - Overall this is very limited as even the example below will only compile up to a linker error.

-- Testing --
 - build dmd from DIP11 branch
 - get download.py: http://codepad.org/XAvSN505
 - get test.d: http://codepad.org/BILAwzHj
 - add 'DOWNLOADTOOL= path/to/download.py' to your /etc/dmd.conf
 - compile: dmd test.d

-- Brainstorming --
We need to define a compilation model for the imported files.

One solution could be to generally change the semantics of importing to mean if the
imported file is a source (*.d) build an object for that module if it is a header (*.di) don't
build an object and leave it to the user to supply binary data.

If I somehow compile the remote sources I might want to do that including debug information.
This would immediately require an offline copy of the sources to work properly.

martin

While thinking about DIP11 I had an idea:
Couldn't the program output dmd flags to stdout. That way the library could be automatically build and there are many other possibilities:
- linking with something
- some needed compilation flags for the lib
etc
What do you think about this?

On Mon, 15 Aug 2011 15:23:27 +0200, Mafi <mafi@example.org> wrote:

> While thinking about DIP11 I had an idea:
> Couldn't the program output dmd flags to stdout. That way the library could be automatically build and there are many other possibilities:
> - linking with something
> - some needed compilation flags for the lib
> etc
> What do you think about this?
>

I think we should find a better way to support this scenario for binary distributions.
With the current draft you would need to put pragma(lib, "mylib") into the remote
sources and the package tool would need to make sure the library is in place before linking.
So we should at least pass machine info and compilation flags to the package tool.
Then it would have the possibility of downloading/building a platform specific library
and set everything up for linking.
A flag response of the tool on stdout could be useful, it would require
a widened interface between compiler/package tool.
But if there is too many information going back and forth it is a clear indication
that the tool should be the driver.

I don't think anything like that is good for source distributions because now the package tool
would need to know how to build a specific library. Not capturing the knowledge of building
in the source code would again require meta-data/source parsing. So it wouldn't be much better
than using a plain package tool.

martin