Why are the .o files from DMD compiler not placed in the source directory of the source .d file?  This never really bothered me before, but it turns out to be annoying if you want similarly named modules in different packages (folders). Granted, I can see that doing a manual cleanup of object files could possibly be a slight pain if they're placed in separate directories, but I see the pain of having a couple dozen .o files in the base folder of the project a bit worse.

Yes, I am aware of the -od option for output directories, but it doesn't apply to an uber monolithic build of passing all source code files in all folders to one instance of dmd for compiling.

I suppose I could use -od to redirect all objects for different programs under the base folder to separate directories, but what a pain.  I'd much rather have the compiler just write the .o file to the same directory as the .d file.

Am I alone on this one or do other people see this as being valuable?

Regards,
James Dunne

"James Dunne" <jdunne4@bradley.edu> wrote in message news:d3krq5$1jv$1@digitaldaemon.com...
> Why are the .o files from DMD compiler not placed in the source directory
of the
> source .d file?  This never really bothered me before, but it turns out to
be
> annoying if you want similarly named modules in different packages
(folders).
> Granted, I can see that doing a manual cleanup of object files could
possibly be
> a slight pain if they're placed in separate directories, but I see the
pain of
> having a couple dozen .o files in the base folder of the project a bit
worse.
>
> Yes, I am aware of the -od option for output directories, but it doesn't
apply
> to an uber monolithic build of passing all source code files in all
folders to
> one instance of dmd for compiling.
>
> I suppose I could use -od to redirect all objects for different programs
under
> the base folder to separate directories, but what a pain.  I'd much rather
have
> the compiler just write the .o file to the same directory as the .d file.
>
> Am I alone on this one or do other people see this as being valuable?

You're not alone. I ran into a similar thing with Mango. Using build.exe takes care of the crap for me now, but that leaves with with a few regrets over non-ideal module names; ones that had to be changed to avoid object file collisions.

I thought that was what the -op switch is for?

[quote]normally the path for .d source files is stripped off when generating an object file name. -op will leave it on.[/quote]

Granted I haven't personally used it yet, so maybe not.

-- Chris Sauls

James Dunne wrote:
> Why are the .o files from DMD compiler not placed in the source directory of the
> source .d file?  This never really bothered me before, but it turns out to be
> annoying if you want similarly named modules in different packages (folders).
> Granted, I can see that doing a manual cleanup of object files could possibly be
> a slight pain if they're placed in separate directories, but I see the pain of
> having a couple dozen .o files in the base folder of the project a bit worse.

Someone should've sent me a nice RTFM then ;).  I didn't even notice that switch.  I'll check it out and report my findings.

In article <d3l61n$9h2$1@digitaldaemon.com>, Chris Sauls says...
>
>I thought that was what the -op switch is for?
>
>[quote]normally the path for .d source files is stripped off when generating an object file name. -op will leave it on.[/quote]
>
>Granted I haven't personally used it yet, so maybe not.
>
>-- Chris Sauls
>
>James Dunne wrote:
>> Why are the .o files from DMD compiler not placed in the source directory of the source .d file?  This never really bothered me before, but it turns out to be annoying if you want similarly named modules in different packages (folders). Granted, I can see that doing a manual cleanup of object files could possibly be a slight pain if they're placed in separate directories, but I see the pain of having a couple dozen .o files in the base folder of the project a bit worse.

Regards,
James Dunne

Works good.  Use it, Kris and others!

In article <d3l9vc$e01$1@digitaldaemon.com>, James Dunne says...
>
>Someone should've sent me a nice RTFM then ;).  I didn't even notice that switch.  I'll check it out and report my findings.
>
>In article <d3l61n$9h2$1@digitaldaemon.com>, Chris Sauls says...
>>
>>I thought that was what the -op switch is for?
>>
>>[quote]normally the path for .d source files is stripped off when generating an object file name. -op will leave it on.[/quote]
>>
>>Granted I haven't personally used it yet, so maybe not.
>>
>>-- Chris Sauls
>>
>>James Dunne wrote:
>>> Why are the .o files from DMD compiler not placed in the source directory of the source .d file?  This never really bothered me before, but it turns out to be annoying if you want similarly named modules in different packages (folders). Granted, I can see that doing a manual cleanup of object files could possibly be a slight pain if they're placed in separate directories, but I see the pain of having a couple dozen .o files in the base folder of the project a bit worse.
>
>Regards,
>James Dunne

Yeah, the DMD compiler doesn't do well at all with filenames and directories in general.  This was the major source of my troubles when I first installed it... and I never did get it quite to my satisfaction, but I got it working, so for now I figure that's good enough.  I'm hoping there are plans to revamp that part of the compiler, and possibly wrap the Windows version in a GUI with common dialogs for file handling, and user changeable default directores stored in an ini file (or the registry, although I like the ini file idea better) that is written by DMD with default values if it doesn't exist.

I didn't have any room left to add one more path to my %path% environment variable, so I'm sure you can imagine the trouble that caused when I installed it onto drive F in the DMD folder rather than the DM folder where it was expecting to exist alongside of the DMC files which I had installed to the DMC folder rather than the DM folder because I wanted to test DMD and DMC separately.  Yep... definately an area that desparately needs some serious work.

TZ

"Kris" <fu@bar.com> wrote in message news:d3ks9e$1v2$1@digitaldaemon.com...
> "James Dunne" <jdunne4@bradley.edu> wrote in message news:d3krq5$1jv$1@digitaldaemon.com...
> > Why are the .o files from DMD compiler not placed in the source directory
> of the
> > source .d file?  This never really bothered me before, but it turns out to
> be
> > annoying if you want similarly named modules in different packages
> (folders).
> > Granted, I can see that doing a manual cleanup of object files could
> possibly be
> > a slight pain if they're placed in separate directories, but I see the
> pain of
> > having a couple dozen .o files in the base folder of the project a bit
> worse.
> >
> > Yes, I am aware of the -od option for output directories, but it doesn't
> apply
> > to an uber monolithic build of passing all source code files in all
> folders to
> > one instance of dmd for compiling.
> >
> > I suppose I could use -od to redirect all objects for different programs
> under
> > the base folder to separate directories, but what a pain.  I'd much rather
> have
> > the compiler just write the .o file to the same directory as the .d file.
> >
> > Am I alone on this one or do other people see this as being valuable?
>
> You're not alone. I ran into a similar thing with Mango. Using build.exe takes care of the crap for me now, but that leaves with with a few regrets over non-ideal module names; ones that had to be changed to avoid object file collisions.
>
>
>