www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Prototype DIP11

reply "Martin Nowak" <dawg dawgfoto.de> writes:
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
Aug 14 2011
parent reply Mafi <mafi example.org> writes:
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?
Aug 15 2011
parent "Martin Nowak" <dawg dawgfoto.de> writes:
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
Aug 15 2011