On Mon, 15 Aug 2011 01:19:29 +0200, Jonathan M Davis <[email protected]>
wrote:
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
Yes I'm aware of this. Prominent example being phobos vs. druntime.
But the idea was exactly to change this (in the long-term/opt-in).
Requiring libraries to be bundled with .di files.
What is needed for DIP11 to work is some sort of pragma(build, pkg.module)
but
- it should not require redundant declarations (already have
pragma(importpath, "pkg"))
- one should be able to define the build model in the remote sources
martin
