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
