• torhu (6/6) May 08 2007 Optlink seems to always output a .map file. From the docs, I can't see
• Derek Parnell (13/20) May 08 2007 This is a 'feature' of DMD. As DMD invokes the linker, it controls what ...
• torhu (4/7) May 09 2007 The problem is that I'm no sure how to figure out where phobos.lib is
• Derek Parnell (8/16) May 10 2007 LOL LOL LOL LOL LOL
• torhu (3/4) May 10 2007 Sure, but this is for a library, so I try not to make it depend on tools...
• Mike Parker (10/15) May 10 2007 I feel the same way about libraries most of the time, but I think Bud
• torhu (8/21) May 11 2007 The problem is when you need to build things like 49 example programs.
• Derek Parnell (7/10) May 11 2007 With Bud, the -clean switch gets rid of any map files created.

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.

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

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.

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

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.

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.

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.

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