Optlink seems to always output a .map file.  From the docs, I can't see any way to avoid this.  Just making it ouput the .map file in the same dir where it outputs the .objs and .exes would help a bit.

I'm creating a makefile for DM make, so I don't have an easy way to get the filename of the .map file, so I can't easily delete it that way either.  Doing 'del *.map' isn't a great solution.

On Tue, 08 May 2007 21:18:19 +0200, torhu wrote:

> Optlink seems to always output a .map file.  From the docs, I can't see any way to avoid this.  Just making it ouput the .map file in the same dir where it outputs the .objs and .exes would help a bit.
> 
> I'm creating a makefile for DM make, so I don't have an easy way to get the filename of the .map file, so I can't easily delete it that way either.  Doing 'del *.map' isn't a great solution.

This is a 'feature' of DMD. As DMD invokes the linker, it controls what the linker's command line is, and it invokes it in a way that always causes the .map file to be created. I had to work hard to eliminate this in Bud. In short, you need to invoke the linker yourself using a response file to pass it the correct style of command line options. It's all there in the OptLInk documentation except the part that you need to set the environment symbol LIB correctly for Phobos just before running the linker.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Derek Parnell wrote:
> It's all there in the OptLInk
> documentation except the part that you need to set the environment symbol
> LIB correctly for Phobos just before running the linker.

The problem is that I'm no sure how to figure out where phobos.lib is located.  Maybe I should use a D program to do the building, and act as a frontend for make.

On Thu, 10 May 2007 00:16:44 +0200, torhu wrote:

> Derek Parnell wrote:
>> It's all there in the OptLInk
>> documentation except the part that you need to set the environment symbol
>> LIB correctly for Phobos just before running the linker.
> 
> The problem is that I'm no sure how to figure out where phobos.lib is located.  Maybe I should use a D program to do the building, and act as a frontend for make.

LOL LOL LOL LOL LOL

You have heard of Rebuild and Bud, no?
-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Derek Parnell wrote:
> You have heard of Rebuild and Bud, no?

Sure, but this is for a library, so I try not to make it depend on tools that doesn't come with the compiler.

torhu wrote:
> Derek Parnell wrote:
>> You have heard of Rebuild and Bud, no?
> 
> Sure, but this is for a library, so I try not to make it depend on tools that doesn't come with the compiler.

I feel the same way about libraries most of the time, but I think Bud and Rebuild are both sufficiently pervasive in the D community that it doesn't matter. For a new library I'm working on, I decided against Tango because it's not really an easy dependency to set up (i.e., not newbie-friendly). But I have no hesitation about requiring Bud to build it. I've long required Bud to build the Derelict libraries and that's worked just fine. In fact, I always recommend that users don't bother with the build script and just use Bud or Rebuild to compile Derelict packages with their apps.

Mike Parker wrote:
> torhu wrote:
>> Sure, but this is for a library, so I try not to make it depend on tools that doesn't come with the compiler.
> 
> I feel the same way about libraries most of the time, but I think Bud and Rebuild are both sufficiently pervasive in the D community that it doesn't matter. For a new library I'm working on, I decided against Tango because it's not really an easy dependency to set up (i.e., not newbie-friendly). But I have no hesitation about requiring Bud to build it. I've long required Bud to build the Derelict libraries and that's worked just fine. In fact, I always recommend that users don't bother with the build script and just use Bud or Rebuild to compile Derelict packages with their apps.

The problem is when you need to build things like 49 example programs. DM make works for that, it's just the .map files that it leaves behind that are annoying.  But I guess it's not that much trouble to create a batch file that does it all with just dmd.  All the dependencies can be listed in a response file, so I don't have to repeat them for each app.

I used to think it was okay to require bud/build, but since Rebuild entered the stage, it's not that 'standard' anymore.

On Fri, 11 May 2007 09:57:09 +0200, torhu wrote:

> The problem is when you need to build things like 49 example programs. DM make works for that, it's just the .map files that it leaves behind that are annoying.

With Bud, the -clean switch gets rid of any map files created.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell