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

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

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

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."

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.

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.

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

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

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

Be aware that if you use an archiver to put these files in a library you'll overwrite one. The command to preserve path name that the archiver provides on some OSes doesn't exist everywhere.

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