On Monday, August 15, 2011 01:12:20 Martin Nowak wrote: > 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.
That's not going to work. That assumes that libraries use .di files, which isn't necessarily true. If a library just uses .d files, then that means that you're recompiling modules from the library when you don't need to (and probably shouldn't be since, I would expect that you'd end up with complaints about symbols being defined twice when you link in the library). - Jonathan M Davis