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
parent reply "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
next sibling parent reply 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
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 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 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 reply "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
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 reply "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
parent reply "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
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
next sibling parent reply "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
parent reply "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
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 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 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 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 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 reply 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
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 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:
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
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 parent reply "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
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=


ote:

=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=




 at once' with Mono-D (IDE plugin) difficult/impossible. As far as I'm conce=
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