www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd -c behaviour doesn't take account of packages.

reply "Bernard Helyer" <b.helyer gmail.com> writes:
A discussion on the Mono-D IRC channel just made me realise 
something.

     dmd -c foo/a.d  bar/a.d

The second module overwrites the first. This makes using 'pass 
everything at once' with Mono-D (IDE plugin) 
difficult/impossible. As far as I'm concerned, it's just a bug 
that's never come up. The solution is trivial, of course. Prepend 
package names so you get foo_a.o and bar_a.o. Either that or 
allow specific output paths to be specified per-object. Or just 
produce one object file. Anything _but_ the current behaviour, in 
fact.
Feb 22 2012
next sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 22 February 2012 at 21:33:36 UTC, Bernard Helyer 
wrote:
     dmd -c foo/a.d  bar/a.d

 The second module overwrites the first.

-oq, anyone? ;) David
Feb 22 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-22 22:37, David Nadlinger wrote:
 On Wednesday, 22 February 2012 at 21:36:10 UTC, David Nadlinger wrote:
 -oq, anyone? ;)

Whoops, forgot the link: https://github.com/D-Programming-Language/dmd/pull/563. David

I've tried to implement that several times but something always fails on Windows. -- /Jacob Carlborg
Feb 23 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-22 23:42, Brad Roberts wrote:
 On Wed, 22 Feb 2012, David Nadlinger wrote:

 On Wednesday, 22 February 2012 at 21:36:10 UTC, David Nadlinger wrote:
 -oq, anyone? ;)

Whoops, forgot the link: https://github.com/D-Programming-Language/dmd/pull/563. David

If only one of the attempts to implement that option actually worked.

Yeah, sorry, my bad. -- /Jacob Carlborg
Feb 23 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 22 February 2012 at 21:36:10 UTC, David Nadlinger 
wrote:
 -oq, anyone? ;)

Whoops, forgot the link: https://github.com/D-Programming-Language/dmd/pull/563. David
Feb 22 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, February 22, 2012 22:33:35 Bernard Helyer wrote:
 A discussion on the Mono-D IRC channel just made me realise
 something.
 
 dmd -c foo/a.d bar/a.d
 
 The second module overwrites the first. This makes using 'pass
 everything at once' with Mono-D (IDE plugin)
 difficult/impossible. As far as I'm concerned, it's just a bug
 that's never come up. The solution is trivial, of course. Prepend
 package names so you get foo_a.o and bar_a.o. Either that or
 allow specific output paths to be specified per-object.

Then what happens when you have dmc -c foo/a.d foo_a.d
 Or just
 produce one object file. Anything _but_ the current behaviour, in
 fact.

Generating one object file would make far more sense. If you're going to worry about modules when generating object files, then you really should be putting the object files in the same directory layout as the modules have. But that sort of thing is arguably a build tool's job, not the compiler. Regardless, I really wouldn't like the idea of screwing with the object file names to try and avoid collisions. If anything, the compiler should complain that dmd -c foo/a.d bar/a.d will result in a conflict, because one file would overwrite the other. But the single object file solution sounds reasonable. - Jonathan M Davis
Feb 22 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-22 23:05, Jonathan M Davis wrote:
 On Wednesday, February 22, 2012 22:33:35 Bernard Helyer wrote:
 A discussion on the Mono-D IRC channel just made me realise
 something.

 dmd -c foo/a.d bar/a.d

 The second module overwrites the first. This makes using 'pass
 everything at once' with Mono-D (IDE plugin)
 difficult/impossible. As far as I'm concerned, it's just a bug
 that's never come up. The solution is trivial, of course. Prepend
 package names so you get foo_a.o and bar_a.o. Either that or
 allow specific output paths to be specified per-object.

Then what happens when you have dmc -c foo/a.d foo_a.d

The way -oq works is the compiler uses the fully qualified name of the module in the file name of the object file. So if foo/a.d has "module foo.a;" and foo_a.d has "module foo_a;" then the following object files will be created: foo.a.o foo_a.o No conflict. If there would have been a conflict with the object files ,it would have been a conflict with the module names as well and the compiler would have stopped before generating the object files.
 Or just
 produce one object file. Anything _but_ the current behaviour, in
 fact.

Generating one object file would make far more sense. If you're going to worry about modules when generating object files, then you really should be putting the object files in the same directory layout as the modules have. But that sort of thing is arguably a build tool's job, not the compiler.

No I don't think so. If the compiler generate object file names based on the fully qualified module name it will be A LOT easier to implement a build tool that can do incremental builds. I don't see any advantage of putting the object files in sub directories.
 Regardless, I really wouldn't like the idea of screwing with the object file
 names to try and avoid collisions. If anything, the compiler should complain
 that

 dmd -c foo/a.d bar/a.d

 will result in a conflict, because one file would overwrite the other. But the
 single object file solution sounds reasonable.

 - Jonathan M Davis

-- /Jacob Carlborg
Feb 23 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-22 23:33, Bernard Helyer wrote:
 On Wednesday, 22 February 2012 at 22:05:51 UTC, Jonathan M Davis wrote:
 Then what happens when you have

 dmc -c foo/a.d foo_a.d

Good point.
 Regardless, I really wouldn't like the idea of screwing with the
 object file
 names to try and avoid collisions.

Well, the thing is in this case everything is being passed to the compiler. It knows the names of everything. But yeah, I think complaining is fine _if_ dmd allows individual modules to be named explicitly. Otherwise, all in one is good. But really, even prefixing it would be better than what we have now. What about 'module.foo_a.o' if foo_a isn't in a package?

See my reply to Jonathan: http://forum.dlang.org/thread/svyqjflmabsxabmnpzrg forum.dlang.org?page=2#post-ji56kf:242j8p:241:40digitalmars.com -- /Jacob Carlborg
Feb 23 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-22 23:43, Jonathan M Davis wrote:
 On Wednesday, February 22, 2012 23:33:57 Bernard Helyer wrote:
 On Wednesday, 22 February 2012 at 22:05:51 UTC, Jonathan M Davis

 wrote:
 Then what happens when you have

 dmc -c foo/a.d foo_a.d

Good point.
 Regardless, I really wouldn't like the idea of screwing with
 the object file
 names to try and avoid collisions.

Well, the thing is in this case everything is being passed to the compiler. It knows the names of everything. But yeah, I think complaining is fine _if_ dmd allows individual modules to be named explicitly. Otherwise, all in one is good. But really, even prefixing it would be better than what we have now. What about 'module.foo_a.o' if foo_a isn't in a package?

I really think that it should either put it in a single object file or complain and disallow it. Really, the correct way to build such modules is to put each object file in a directory hierarchy which matches the modules. Anything else is a mess. But that's the job a build tool, not the compiler. So, it should do what's reasonable, which doesn't include renaming files to avoid module collisions IMHO. - Jonathan M Davis

I don't agree. The compiler should just put the object files in the same directory and use the fully qualified module name. -- /Jacob Carlborg
Feb 23 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Wednesday, 22 February 2012 at 22:05:51 UTC, Jonathan M Davis 
wrote:
 Then what happens when you have

 dmc -c foo/a.d foo_a.d

Good point.
 Regardless, I really wouldn't like the idea of screwing with 
 the object file
 names to try and avoid collisions.

Well, the thing is in this case everything is being passed to the compiler. It knows the names of everything. But yeah, I think complaining is fine _if_ dmd allows individual modules to be named explicitly. Otherwise, all in one is good. But really, even prefixing it would be better than what we have now. What about 'module.foo_a.o' if foo_a isn't in a package?
Feb 22 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On Wed, 22 Feb 2012, David Nadlinger wrote:

 On Wednesday, 22 February 2012 at 21:36:10 UTC, David Nadlinger wrote:
 -oq, anyone? ;)

Whoops, forgot the link: https://github.com/D-Programming-Language/dmd/pull/563. David

If only one of the attempts to implement that option actually worked.
Feb 22 2012
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, February 22, 2012 23:33:57 Bernard Helyer wrote:
 On Wednesday, 22 February 2012 at 22:05:51 UTC, Jonathan M Davis
 
 wrote:
 Then what happens when you have
 
 dmc -c foo/a.d foo_a.d

Good point.
 Regardless, I really wouldn't like the idea of screwing with
 the object file
 names to try and avoid collisions.

Well, the thing is in this case everything is being passed to the compiler. It knows the names of everything. But yeah, I think complaining is fine _if_ dmd allows individual modules to be named explicitly. Otherwise, all in one is good. But really, even prefixing it would be better than what we have now. What about 'module.foo_a.o' if foo_a isn't in a package?

I really think that it should either put it in a single object file or complain and disallow it. Really, the correct way to build such modules is to put each object file in a directory hierarchy which matches the modules. Anything else is a mess. But that's the job a build tool, not the compiler. So, it should do what's reasonable, which doesn't include renaming files to avoid module collisions IMHO. - Jonathan M Davis
Feb 22 2012
next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= writes:
Am 23.02.2012 00:03, schrieb Jonathan M Davis:
 On Wednesday, February 22, 2012 23:50:53 Bernard Helyer wrote:
 Except DMD is faster by a factor of 10 when passing it all at
 once.

Then maybe there _should_ be a flag to tell it to use/generate the appropriate directory structure. You already typically give it an output directory. It wouldn't be all that hard for it to then generate and use the correct directories in that directory. That still bugs me a little, because that's more of a build tool's job, but it wouldn't be hard to do, would fix the file conflicts across modules, and would let you keep that extra speed. - Jonathan M Davis

Am I not seeing something obvious in this discussion, or is there something that "dmd -op -c ..." or "dmd -odobj -op -c ..." would do wrong?
Feb 23 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-02-23 00:03, Jonathan M Davis wrote:
 On Wednesday, February 22, 2012 23:50:53 Bernard Helyer wrote:
 Except DMD is faster by a factor of 10 when passing it all at
 once.

Then maybe there _should_ be a flag to tell it to use/generate the appropriate directory structure. You already typically give it an output directory. It wouldn't be all that hard for it to then generate and use the correct directories in that directory. That still bugs me a little, because that's more of a build tool's job, but it wouldn't be hard to do, would fix the file conflicts across modules, and would let you keep that extra speed. - Jonathan M Davis

I don't see a point in putting the object files in different directories when the compiler can output the object files with fully qualified module names. -- /Jacob Carlborg
Feb 23 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-02-24 00:06, Bernard Helyer wrote:
 On Thursday, 23 February 2012 at 21:28:17 UTC, H. S. Teoh wrote:
 On Thu, Feb 23, 2012 at 01:42:44PM +0100, Jacob Carlborg wrote:
 On 2012-02-23 00:03, Jonathan M Davis wrote:
On Wednesday, February 22, 2012 23:50:53 Bernard Helyer wrote:
Except DMD is faster by a factor of 10 when passing it all >>at once.

Then maybe there _should_ be a flag to tell it to >use/generate the appropriate directory structure. You already typically give >it an output directory. It wouldn't be all that hard for it to then generate and use the correct directories in that directory. >That still bugs me a little, because that's more of a build tool's >job, but it wouldn't be hard to do, would fix the file conflicts >across modules, and would let you keep that extra speed. - Jonathan M Davis

I don't see a point in putting the object files in different directories when the compiler can output the object files with fully qualified module names.

Because ambiguity can arise. Like my/module/A.d -> my_module_A.o my_module_A.d -> my_module_A.o (conflict) my_module/A.d -> my_module_A.o (conflict) my/module_A.d -> my_module_A.o (conflict) Granted, this is a really contrived example, but unexpected coincidences like that do happen. T

Did you not read what Jacob posted? my.module.A.o my_module_A.o my_module.A.o my.module_A.o No conflicts.

Exactly. -- /Jacob Carlborg
Feb 23 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Wednesday, 22 February 2012 at 22:44:15 UTC, Jonathan M Davis 
wrote:
 On Wednesday, February 22, 2012 23:33:57 Bernard Helyer wrote:
 On Wednesday, 22 February 2012 at 22:05:51 UTC, Jonathan M 
 Davis
 
 wrote:
 Then what happens when you have
 
 dmc -c foo/a.d foo_a.d

Good point.
 Regardless, I really wouldn't like the idea of screwing with
 the object file
 names to try and avoid collisions.

Well, the thing is in this case everything is being passed to the compiler. It knows the names of everything. But yeah, I think complaining is fine _if_ dmd allows individual modules to be named explicitly. Otherwise, all in one is good. But really, even prefixing it would be better than what we have now. What about 'module.foo_a.o' if foo_a isn't in a package?

I really think that it should either put it in a single object file or complain and disallow it. Really, the correct way to build such modules is to put each object file in a directory hierarchy which matches the modules. Anything else is a mess. But that's the job a build tool, not the compiler.

Except DMD is faster by a factor of 10 when passing it all at once.
Feb 22 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, February 22, 2012 23:50:53 Bernard Helyer wrote:
 Except DMD is faster by a factor of 10 when passing it all at
 once.

Then maybe there _should_ be a flag to tell it to use/generate the appropriate directory structure. You already typically give it an output directory. It wouldn't be all that hard for it to then generate and use the correct directories in that directory. That still bugs me a little, because that's more of a build tool's job, but it wouldn't be hard to do, would fix the file conflicts across modules, and would let you keep that extra speed. - Jonathan M Davis
Feb 22 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 05:05:40PM -0500, Jonathan M Davis wrote:
 On Wednesday, February 22, 2012 22:33:35 Bernard Helyer wrote:
 A discussion on the Mono-D IRC channel just made me realise
 something.
 
 dmd -c foo/a.d bar/a.d
 
 The second module overwrites the first. This makes using 'pass
 everything at once' with Mono-D (IDE plugin) difficult/impossible.
 As far as I'm concerned, it's just a bug that's never come up. The
 solution is trivial, of course. Prepend package names so you get
 foo_a.o and bar_a.o. Either that or allow specific output paths to
 be specified per-object.


The real solution is that when creating object files, dmd should put the .o files in the modules' respective subdirectories. I.e., it should keep the pathname component of every source file and use that for the object file. Then you have a 1-to-1 mapping between source files and object files. Either that, or duplicate the source tree structure in an object tree (if you like that kind of compile structure -- some projects do that). Everything else is just a hack and prone to errors. T -- My program has no bugs! Only unintentional features...
Feb 22 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, February 22, 2012 16:08:20 H. S. Teoh wrote:
 On Wed, Feb 22, 2012 at 05:05:40PM -0500, Jonathan M Davis wrote:
 On Wednesday, February 22, 2012 22:33:35 Bernard Helyer wrote:
 A discussion on the Mono-D IRC channel just made me realise
 something.
 
 dmd -c foo/a.d bar/a.d
 
 The second module overwrites the first. This makes using 'pass
 everything at once' with Mono-D (IDE plugin) difficult/impossible.
 As far as I'm concerned, it's just a bug that's never come up. The
 solution is trivial, of course. Prepend package names so you get
 foo_a.o and bar_a.o. Either that or allow specific output paths to
 be specified per-object.


[...] The real solution is that when creating object files, dmd should put the .o files in the modules' respective subdirectories. I.e., it should keep the pathname component of every source file and use that for the object file. Then you have a 1-to-1 mapping between source files and object files.

Yuck. Yuck. Source should _always_ be separated from object files. It's incredibly messy otherwise.
 Either that, or duplicate the source tree structure in an object tree
 (if you like that kind of compile structure -- some projects do that).

That's definitely the way to organize things. - Jonathan M Davis
Feb 22 2012
prev sibling next sibling parent Kevin Cox <kevincox.ca gmail.com> writes:
--000e0ce03ec60b7d8504b996a252
Content-Type: text/plain; charset=UTF-8

Although I agree that sources and objects should be sperated there are some
benifits.  All tools know where to look for the objects.  And is not
dificult to keep out of scm.  A great example of this is Haskell.  To
compile an app you only need to specify the main file and it finds all the
included modules, only recompiling if nessary.  And if I remember correctly
it also spits out a "definition list" type file that is great for things
like code completion.
On Feb 22, 2012 7:15 PM, "Jonathan M Davis" <jmdavisProg gmx.com> wrote:

 On Wednesday, February 22, 2012 16:08:20 H. S. Teoh wrote:
 On Wed, Feb 22, 2012 at 05:05:40PM -0500, Jonathan M Davis wrote:
 On Wednesday, February 22, 2012 22:33:35 Bernard Helyer wrote:
 A discussion on the Mono-D IRC channel just made me realise
 something.

 dmd -c foo/a.d bar/a.d

 The second module overwrites the first. This makes using 'pass
 everything at once' with Mono-D (IDE plugin) difficult/impossible.
 As far as I'm concerned, it's just a bug that's never come up. The
 solution is trivial, of course. Prepend package names so you get
 foo_a.o and bar_a.o. Either that or allow specific output paths to
 be specified per-object.


[...] The real solution is that when creating object files, dmd should put the .o files in the modules' respective subdirectories. I.e., it should keep the pathname component of every source file and use that for the object file. Then you have a 1-to-1 mapping between source files and object files.

Yuck. Yuck. Source should _always_ be separated from object files. It's incredibly messy otherwise.
 Either that, or duplicate the source tree structure in an object tree
 (if you like that kind of compile structure -- some projects do that).

That's definitely the way to organize things. - Jonathan M Davis

--000e0ce03ec60b7d8504b996a252 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p>Although I agree that sources and objects should be sperated there are s= ome benifits.=C2=A0 All tools know where to look for the objects.=C2=A0 And= is not dificult to keep out of scm.=C2=A0 A great example of this is Haske= ll.=C2=A0 To compile an app you only need to specify the main file and it f= inds all the included modules, only recompiling if nessary.=C2=A0 And if I = remember correctly it also spits out a &quot;definition list&quot; type fil= e that is great for things like code completion.</p> <div class=3D"gmail_quote">On Feb 22, 2012 7:15 PM, &quot;Jonathan M Davis&= quot; &lt;<a href=3D"mailto:jmdavisProg gmx.com">jmdavisProg gmx.com</a>&gt= ; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D= "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Wednesday, February 22, 2012 16:08:20 H. S. Teoh wrote:<br> &gt; On Wed, Feb 22, 2012 at 05:05:40PM -0500, Jonathan M Davis wrote:<br> &gt; &gt; On Wednesday, February 22, 2012 22:33:35 Bernard Helyer wrote:<br=

br> &gt; &gt; &gt; something.<br> &gt; &gt; &gt;<br> &gt; &gt; &gt; dmd -c foo/a.d bar/a.d<br> &gt; &gt; &gt;<br> &gt; &gt; &gt; The second module overwrites the first. This makes using &#3= 9;pass<br> &gt; &gt; &gt; everything at once&#39; with Mono-D (IDE plugin) difficult/i= mpossible.<br> &gt; &gt; &gt; As far as I&#39;m concerned, it&#39;s just a bug that&#39;s = never come up. The<br> &gt; &gt; &gt; solution is trivial, of course. Prepend package names so you= get<br> &gt; &gt; &gt; foo_a.o and bar_a.o. Either that or allow specific output pa= ths to<br> &gt; &gt; &gt; be specified per-object.<br> &gt;<br> &gt; [...]<br> &gt;<br> &gt; The real solution is that when creating object files, dmd should put t= he<br> &gt; .o files in the modules&#39; respective subdirectories. I.e., it shoul= d keep<br> &gt; the pathname component of every source file and use that for the objec= t<br> &gt; file. Then you have a 1-to-1 mapping between source files and object<b= r> &gt; files.<br> <br> Yuck. Yuck. Source should _always_ be separated from object files. It&#39;s= <br> incredibly messy otherwise.<br> <br> &gt; Either that, or duplicate the source tree structure in an object tree<= br> &gt; (if you like that kind of compile structure -- some projects do that).= <br> <br> That&#39;s definitely the way to organize things.<br> <br> - Jonathan M Davis<br> </blockquote></div> --000e0ce03ec60b7d8504b996a252--
Feb 22 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 07:15:37PM -0500, Jonathan M Davis wrote:
 On Wednesday, February 22, 2012 16:08:20 H. S. Teoh wrote:

 The real solution is that when creating object files, dmd should put
 the .o files in the modules' respective subdirectories. I.e., it
 should keep the pathname component of every source file and use that
 for the object file. Then you have a 1-to-1 mapping between source
 files and object files.

Yuck. Yuck. Source should _always_ be separated from object files. It's incredibly messy otherwise.

Not really. You just have .d's with their corresponding .o's sitting side-by-side. It's a 1-to-1 correspondence. No mess.
 Either that, or duplicate the source tree structure in an object
 tree (if you like that kind of compile structure -- some projects do
 that).

That's definitely the way to organize things.

To each his own. :) But either way, the point is that the source tree structure *must* be reflected by the object files. Otherwise you break the 1-to-1 correspondence and all sorts of nasty bugs show up. T -- It only takes one twig to burn down a forest.
Feb 22 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, February 22, 2012 16:28:45 H. S. Teoh wrote:
 On Wed, Feb 22, 2012 at 07:15:37PM -0500, Jonathan M Davis wrote:
 Yuck. Yuck. Source should _always_ be separated from object files.
 It's incredibly messy otherwise.

Not really. You just have .d's with their corresponding .o's sitting side-by-side. It's a 1-to-1 correspondence. No mess.

I would consider the fact that they're in the same folder to be a mess in and of itself even without going into the other pros and cons, but there's no point in getting in an argument about it.
 But either way, the point is that the source tree structure *must* be
 reflected by the object files. Otherwise you break the 1-to-1
 correspondence and all sorts of nasty bugs show up.

Definitely. - Jonathan M Davis
Feb 22 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Feb 22, 2012 at 09:36:12PM -0500, Jonathan M Davis wrote:
 On Wednesday, February 22, 2012 16:28:45 H. S. Teoh wrote:
 On Wed, Feb 22, 2012 at 07:15:37PM -0500, Jonathan M Davis wrote:
 Yuck. Yuck. Source should _always_ be separated from object files.
 It's incredibly messy otherwise.

Not really. You just have .d's with their corresponding .o's sitting side-by-side. It's a 1-to-1 correspondence. No mess.

I would consider the fact that they're in the same folder to be a mess in and of itself even without going into the other pros and cons, but there's no point in getting in an argument about it.

You're entitled to your opinion. :) I just prefer to keep things in one place if there's no confusion caused. T -- IBM = I Blame Microsoft
Feb 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, February 23, 2012 12:06:54 Jacob Carlborg wrote:
 On 2012-02-22 23:05, Jonathan M Davis wrote:
 If you're going to worry about modules when generating object files, then
 you really should be putting the object files in the same directory
 layout as the modules have. But that sort of thing is arguably a build
 tool's job, not the compiler.

No I don't think so. If the compiler generate object file names based on the fully qualified module name it will be A LOT easier to implement a build tool that can do incremental builds. I don't see any advantage of putting the object files in sub directories.

Because then it nicely matches the layout of the source code. It's certainly the typical thing to do with many projects in other languages. It also keeps the object files separate from the source files, which makes for cleaner directories, fewer issues with source control, easier cleaning of builds, etc. (at least in comparison to putting them in the same directories as the source, which some folks do). - Jonathan M Davis
Feb 23 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Feb 23, 2012 at 01:42:44PM +0100, Jacob Carlborg wrote:
 On 2012-02-23 00:03, Jonathan M Davis wrote:
On Wednesday, February 22, 2012 23:50:53 Bernard Helyer wrote:
Except DMD is faster by a factor of 10 when passing it all at once.

Then maybe there _should_ be a flag to tell it to use/generate the appropriate directory structure. You already typically give it an output directory. It wouldn't be all that hard for it to then generate and use the correct directories in that directory. That still bugs me a little, because that's more of a build tool's job, but it wouldn't be hard to do, would fix the file conflicts across modules, and would let you keep that extra speed. - Jonathan M Davis

I don't see a point in putting the object files in different directories when the compiler can output the object files with fully qualified module names.

Because ambiguity can arise. Like my/module/A.d -> my_module_A.o my_module_A.d -> my_module_A.o (conflict) my_module/A.d -> my_module_A.o (conflict) my/module_A.d -> my_module_A.o (conflict) Granted, this is a really contrived example, but unexpected coincidences like that do happen. T -- "Hi." "'Lo."
Feb 23 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Thursday, 23 February 2012 at 21:28:17 UTC, H. S. Teoh wrote:
 On Thu, Feb 23, 2012 at 01:42:44PM +0100, Jacob Carlborg wrote:
 On 2012-02-23 00:03, Jonathan M Davis wrote:
On Wednesday, February 22, 2012 23:50:53 Bernard Helyer wrote:
Except DMD is faster by a factor of 10 when passing it all 
at once.

Then maybe there _should_ be a flag to tell it to use/generate the appropriate directory structure. You already typically give it an output directory. It wouldn't be all that hard for it to then generate and use the correct directories in that directory. That still bugs me a little, because that's more of a build tool's job, but it wouldn't be hard to do, would fix the file conflicts across modules, and would let you keep that extra speed. - Jonathan M Davis

I don't see a point in putting the object files in different directories when the compiler can output the object files with fully qualified module names.

Because ambiguity can arise. Like my/module/A.d -> my_module_A.o my_module_A.d -> my_module_A.o (conflict) my_module/A.d -> my_module_A.o (conflict) my/module_A.d -> my_module_A.o (conflict) Granted, this is a really contrived example, but unexpected coincidences like that do happen. T

Did you not read what Jacob posted? my.module.A.o my_module_A.o my_module.A.o my.module_A.o No conflicts.
Feb 23 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Thursday, 23 February 2012 at 23:06:56 UTC, Bernard Helyer
wrote:
 Did you not read what Jacob posted?

 my.module.A.o
 my_module_A.o
 my_module.A.o
 my.module_A.o

 No conflicts.

Also, you can't have a package called module.
Feb 23 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, February 23, 2012 13:42:44 Jacob Carlborg wrote:
 On 2012-02-23 00:03, Jonathan M Davis wrote:
 On Wednesday, February 22, 2012 23:50:53 Bernard Helyer wrote:
 Except DMD is faster by a factor of 10 when passing it all at
 once.

Then maybe there _should_ be a flag to tell it to use/generate the appropriate directory structure. You already typically give it an output directory. It wouldn't be all that hard for it to then generate and use the correct directories in that directory. That still bugs me a little, because that's more of a build tool's job, but it wouldn't be hard to do, would fix the file conflicts across modules, and would let you keep that extra speed. - Jonathan M Davis

I don't see a point in putting the object files in different directories when the compiler can output the object files with fully qualified module names.

It organizes things better IMHO to have them in a separate directory hierarchy which matches the source's directory hierarchy, but outputing modules with fully qualified modules names does solve the core problem as long as it can be done in a manner that's not going to result in conflicts (which you've shown a way to do). A build tool can organize the object files differently if you want it to. Worrying about the directory structure is the sort of thing that's better left to a build tool anyway. I was pointing out that I thought that using a separate directory structure is the ideal way to go and that the previous suggestion of renaming modules wouldn't work. The only remaining issue then is the fact that dmd is faster when compiling multiple modules at once, which ends up making it so that using a build tool to build each module separately to organize it how you want would result in a slower build. But that may just be the way that life goes. - Jonathan M Davis
Feb 24 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Wed, 22 Feb 2012 22:33:35 +0100, Bernard Helyer <b.helyer gmail.com>  
wrote:

 A discussion on the Mono-D IRC channel just made me realise something.

      dmd -c foo/a.d  bar/a.d

 The second module overwrites the first. This makes using 'pass  
 everything at once' with Mono-D (IDE plugin) difficult/impossible. As  
 far as I'm concerned, it's just a bug that's never come up. The solution  
 is trivial, of course. Prepend package names so you get foo_a.o and  
 bar_a.o. Either that or allow specific output paths to be specified  
 per-object. Or just produce one object file. Anything _but_ the current  
 behaviour, in fact.

use '-op' to preserve the directory structure use '-od' to set the root directory mkdir foo bar echo "module foo.a;" > foo/a.d echo "module bar.a;" > bar/a.d dmd -c -op -odout foo/a.d bar/a.d tree out rm -r foo bar out
Feb 25 2012
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Be aware that if you use an archiver to put these files in a library you'll o=
verwrite one. The command to preserve path name that the archiver provides o=
n some OSes doesn't exist everywhere.=20

On Feb 25, 2012, at 7:09 AM, "Martin Nowak" <dawg dawgfoto.de> wrote:

 On Wed, 22 Feb 2012 22:33:35 +0100, Bernard Helyer <b.helyer gmail.com> wr=

=20
 A discussion on the Mono-D IRC channel just made me realise something.
=20
     dmd -c foo/a.d  bar/a.d
=20
 The second module overwrites the first. This makes using 'pass everything=


rned, it's just a bug that's never come up. The solution is trivial, of cour= se. Prepend package names so you get foo_a.o and bar_a.o. Either that or all= ow specific output paths to be specified per-object. Or just produce one obj= ect file. Anything _but_ the current behaviour, in fact.
=20
 use '-op' to preserve the directory structure
 use '-od' to set the root directory
=20
 mkdir foo bar
 echo "module foo.a;" > foo/a.d
 echo "module bar.a;" > bar/a.d
 dmd -c -op -odout foo/a.d bar/a.d
 tree out
 rm -r foo bar out

Feb 25 2012