www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Clarification about compilation model and the mapping of package

reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
Imagine you have a module "main.d" with the line `import xxx.foo;`, and 
you have a file "foo.d" with the module declaration `module xxx.foo;`. 
Now imagine the files are laid out like this:

src/main.d
src/foo.d

Is this valid, should these files compile? Currently DMD will fail if 
each file is compiled individually (because it expects `xxx.foo` to be 
in "src/xxx/foo.d", *but* it will succeed if all files are supplied to 
DMD in the same command-line.

Now, while it might not be the remit of the compiler to define a 
standard of the compilation model, and how source modules are supposed 
to be laid out in a project's directory, it is at the very least the 
responsibility of the DUB spec to do so.

And if DUB is to become the official bundle manager, this behavior 
should be clarified, because actually, this non standard layout 
currently works under DUB (because DUB supplies all source files in one 
single DMD invocation). But DUB and other tools need to know if this is 
actually valid or not, and if it's not, there should be some compiler 
switch to error out on situations like those.


FYI, this issue came up because the DDT IDE failed to understand such 
non-standard module layout, according to a user report ( 
https://groups.google.com/d/msg/ddt-ide/Qf8PeQcujbM/UcdRS7VKLwAJ ).


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Apr 29 2016
next sibling parent reply Dicebot <public dicebot.lv> writes:
On 04/29/2016 05:32 PM, Bruno Medeiros wrote:

 Imagine you have a module "main.d" with the line `import xxx.foo;`, and
 you have a file "foo.d" with the module declaration `module xxx.foo;`.
 Now imagine the files are laid out like this:
 
 src/main.d
 src/foo.d
 
 Is this valid, should these files compile? Currently DMD will fail if
 each file is compiled individually (because it expects `xxx.foo` to be
 in "src/xxx/foo.d", *but* it will succeed if all files are supplied to
 DMD in the same command-line.


AFAIK yes, this is valid and shall compile (and there are quite some
projects relying on it). There is simply a missing feature for separate
compilation case to allow supplying import module paths manually.
Apr 29 2016
next sibling parent Claude <no no.no> writes:
On Friday, 29 April 2016 at 14:50:34 UTC, Dicebot wrote:

 On 04/29/2016 05:32 PM, Bruno Medeiros wrote:

 Imagine you have a module "main.d" with the line `import 
 xxx.foo;`, and you have a file "foo.d" with the module 
 declaration `module xxx.foo;`. Now imagine the files are laid 
 out like this:
 
 src/main.d
 src/foo.d
 
 Is this valid, should these files compile? Currently DMD will 
 fail if each file is compiled individually (because it expects 
 `xxx.foo` to be in "src/xxx/foo.d", *but* it will succeed if 
 all files are supplied to DMD in the same command-line.


 AFAIK yes, this is valid and shall compile (and there are quite 
 some projects relying on it). There is simply a missing feature 
 for separate compilation case to allow supplying import module 
 paths manually.


That means that using the layout above, there is no way to 
compile individually "main.d" or a file named "bar.d" with 
"import xxx.foo;" ??

What if I want to make a library out of bar.d without totally 
compiling foo.d?

I understand there must be some analysis of foo.d to get its 
interface (basically get the ".di" version of it) but it should 
not have to compile its implementation.
Apr 29 2016
prev sibling parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 29/04/2016 15:50, Dicebot wrote:

 On 04/29/2016 05:32 PM, Bruno Medeiros wrote:

 Imagine you have a module "main.d" with the line `import xxx.foo;`, and
 you have a file "foo.d" with the module declaration `module xxx.foo;`.
 Now imagine the files are laid out like this:

 src/main.d
 src/foo.d

 Is this valid, should these files compile? Currently DMD will fail if
 each file is compiled individually (because it expects `xxx.foo` to be
 in "src/xxx/foo.d", *but* it will succeed if all files are supplied to
 DMD in the same command-line.


 AFAIK yes, this is valid and shall compile (and there are quite some
 projects relying on it). There is simply a missing feature for separate
 compilation case to allow supplying import module paths manually.


"supplying import module paths manually" ? How would that even work? 
Suppose you want to compile main.d separately. You'd need to supply to 
the compiler an option for each module with non-standard path, such as 
`xxx.foo=foo.d;xxx.bar=bar.d`, etc..

Sounds like a terrible idea. The tool invoking dmd would have to keep a 
cache of these mappings. More complexity and for what benefit? That 
there are projects relying on it says nothing of whether is a good idea.

The DDT semantic engine does not support this kind of layout. I wonder 
if DCD or Mono-D support this (I don't have them handy to try it out).

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Apr 29 2016
parent reply Claude <no no.no> writes:
 "supplying import module paths manually" ? How would that even 
 work? Suppose you want to compile main.d separately. You'd need 
 to supply to the compiler an option for each module with 
 non-standard path, such as `xxx.foo=foo.d;xxx.bar=bar.d`, etc..


No, the command-line option could be much simpler:
dmd -c myimplementation.d -Imyinterface.d

Just like when you compile and link both myimplementation.d and 
myinterface.d (and it resolves import locations on its own). 
Except you tell the compiler it just needs to look for 
declarations within myinterface.d, and not actually compiling it.
Apr 29 2016
parent Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 29/04/2016 17:49, Claude wrote:

 "supplying import module paths manually" ? How would that even work?
 Suppose you want to compile main.d separately. You'd need to supply to
 the compiler an option for each module with non-standard path, such as
 `xxx.foo=foo.d;xxx.bar=bar.d`, etc..


 No, the command-line option could be much simpler:
 dmd -c myimplementation.d -Imyinterface.d

 Just like when you compile and link both myimplementation.d and
 myinterface.d (and it resolves import locations on its own). Except you
 tell the compiler it just needs to look for declarations within
 myinterface.d, and not actually compiling it.


Fair enough, that does make it a simpler option. I still don't like it 
though.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Apr 29 2016
prev sibling next sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
It is de facto allowed, yes. But if it only works in
compile-at-once, and isn't essential for some use case, it is
just friction and I agree to forcing package names to match
their paths. But I suspect there is _are_ use cases. It's not
the first time we talk about this, IIRC.

-- 
Marco
Apr 29 2016
parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Friday, 29 April 2016 at 14:54:30 UTC, Marco Leise wrote:

 It is de facto allowed, yes. But if it only works in 
 compile-at-once, and isn't essential for some use case, it is 
 just friction and I agree to forcing package names to match 
 their paths. But I suspect there is _are_ use cases. It's not 
 the first time we talk about this, IIRC.


It is specifically allowed. Walter felt it was important to allow 
the compiler to compile source files that weren't in the expected 
structure. I don't remember the use case, something like 
downloading a file from the web that is expected to be in package 
one.two.three.four but not actually wanting to recreate that 
structure for the one file.

The only time this is required is when DMD is trying to find the 
module. You can then do separate compilation by having a .di file 
which does follow the correct package-path while the .d file sits 
next to the other .d files (why you would do that I don't know).
Apr 29 2016
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 29 April 2016 at 14:32:05 UTC, Bruno Medeiros wrote:

 Is this valid, should these files compile?


Yes, that is perfectly valid according to the language and the 
compiler and really useful too.
Apr 29 2016
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 29/04/2016 16:02, Adam D. Ruppe wrote:

 On Friday, 29 April 2016 at 14:32:05 UTC, Bruno Medeiros wrote:

 Is this valid, should these files compile?


 Yes, that is perfectly valid according to the language and the compiler
 and really useful too.


Why is this useful in any substantial way?


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Apr 29 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 29 April 2016 at 16:14:30 UTC, Bruno Medeiros wrote:

 Why is this useful in any substantial way?


I use modules for grouping compile time configuration options in 
independent files that can be swapped out. The module name 
doesn't match the file name because there are several files with 
the same module name, only one of which is used at a time.

It is also valuable to swap out library implementations. For 
example, when modifying Phobos modules, instead of recompiling 
the whole thing, I can just specify the path to my modified 
version.

dmd yourfile.d phobosfork.d

no need to recreate layers of folders just to appease a random 
rule.

I also hate having empty folders laying around, and matching 
names would force that.
Apr 29 2016
parent reply Bruno Medeiros <bruno.do.medeiros+dng gmail.com> writes:
On 29/04/2016 18:20, Adam D. Ruppe wrote:

 On Friday, 29 April 2016 at 16:14:30 UTC, Bruno Medeiros wrote:

 Why is this useful in any substantial way?


 I use modules for grouping compile time configuration options in
 independent files that can be swapped out. The module name doesn't match
 the file name because there are several files with the same module name,
 only one of which is used at a time.


Are you using DUB here?


 It is also valuable to swap out library implementations. For example,
 when modifying Phobos modules, instead of recompiling the whole thing, I
 can just specify the path to my modified version.

 dmd yourfile.d phobosfork.d

 no need to recreate layers of folders just to appease a random rule.

 I also hate having empty folders laying around, and matching names would
 force that.


To be clear, I don't mind that DMD itself allows such behavior. But I 
would like it to be invalid for DUB bundles. So some of those cases you 
mentioned wouldn't be affected, like modifying Phobos modules.

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros
Apr 29 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 29 April 2016 at 17:44:51 UTC, Bruno Medeiros wrote:

 Are you using DUB here?


No, dub is useless to me.


 To be clear, I don't mind that DMD itself allows such behavior. 
 But I would like it to be invalid for DUB bundles. So some of 
 those cases you mentioned wouldn't be affected, like modifying 
 Phobos modules.


OK, I can live with that.
Apr 29 2016
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Friday, 29 April 2016 at 17:44:51 UTC, Bruno Medeiros wrote:

 On 29/04/2016 18:20, Adam D. Ruppe wrote:

 On Friday, 29 April 2016 at 16:14:30 UTC, Bruno Medeiros wrote:

 Why is this useful in any substantial way?


 I use modules for grouping compile time configuration options 
 in
 independent files that can be swapped out. The module name 
 doesn't match
 the file name because there are several files with the same 
 module name,
 only one of which is used at a time.


 Are you using DUB here?


 It is also valuable to swap out library implementations. For 
 example,
 when modifying Phobos modules, instead of recompiling the 
 whole thing, I
 can just specify the path to my modified version.

 dmd yourfile.d phobosfork.d

 no need to recreate layers of folders just to appease a random 
 rule.

 I also hate having empty folders laying around, and matching 
 names would
 force that.


 To be clear, I don't mind that DMD itself allows such behavior. 
 But I would like it to be invalid for DUB bundles. So some of 
 those cases you mentioned wouldn't be affected, like modifying 
 Phobos modules.


I agree at 100%. If an IDE has to register a DUB package, the dot 
in the module names must means "folder". Otherwise the software 
cannot determine where is the source of the package and then the 
user has to do it by itself. If the user has to do it by himself 
than what's an IDE for ?
Aug 01 2016