Prototype DIP11
Martin Nowak
dawg at dawgfoto.de
Sun Aug 14 16:32:02 PDT 2011
On Mon, 15 Aug 2011 01:19:29 +0200, Jonathan M Davis <jmdavisProg at gmx.com>
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
More information about the Digitalmars-d
mailing list