www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Make Optlink not create a .map file

reply torhu <fake address.dude> writes:
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.
May 08 2007
parent reply Derek Parnell <derek psych.ward> writes:
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
May 08 2007
parent reply torhu <fake address.dude> writes:
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.
May 09 2007
parent reply Derek Parnell <derek psych.ward> writes:
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
May 10 2007
parent reply torhu <fake address.dude> writes:
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.
May 10 2007
parent reply Mike Parker <aldacron71 yahoo.com> writes:
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.
May 10 2007
parent reply torhu <fake address.dude> writes:
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.
May 11 2007
parent Derek Parnell <derek psych.ward> writes:
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
May 11 2007