www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Build version 3.00

reply Derek Parnell <derek psych.ward> writes:
The next release of Build is now available. 

See http://www.dsource.org/projects/build/wiki for more details.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
6/06/2006 3:42:09 PM
Jun 05 2006
next sibling parent reply dickl <dick221z yahoo.com> writes:
Derek Parnell wrote:

 The next release of Build is now available. 
 
 See http://www.dsource.org/projects/build/wiki for more details.
 


Under Windows, Build seems to think that every file for which there is a 
rule is a Windows Resource File.

For example, I have a rule to take "resource.h" and make "resource.d" so 
it can be included by other modules. Build executes the rule creates the 
.KSP file as follows

foo.obj+resource.obj
foo.exe
foo.map
gdi32.lib+advapi32.lib+(and etc)
foo.def
foo.res+resource.d
/noi/map

The linker doesn't like resource.d as a resource file.

The rule looks like this:

rule=ResourceDefs
in=h
out=d
tool=makeid { IN} { OUT}


The problem should also extend to any rule that doesn't create a 
resource file but haven't verified that.

A quick fix would be to add a check in ProcessExternal() to only pass 
files with the extension ".RES" to AddLink().
Jun 06 2006
parent Derek Parnell <derek psych.ward> writes:
On Tue, 06 Jun 2006 10:48:42 -0400, dickl wrote:


 Derek Parnell wrote:

 The next release of Build is now available. 
 
 See http://www.dsource.org/projects/build/wiki for more details.
 


 
 Under Windows, Build seems to think that every file for which there is a 
 rule is a Windows Resource File.
 
 For example, I have a rule to take "resource.h" and make "resource.d" so 
 it can be included by other modules. Build executes the rule creates the 
 .KSP file as follows
 
 foo.obj+resource.obj
 foo.exe
 foo.map
 gdi32.lib+advapi32.lib+(and etc)
 foo.def
 foo.res+resource.d
 /noi/map
 
 The linker doesn't like resource.d as a resource file.
 
 The rule looks like this:
 
 rule=ResourceDefs
 in=h
 out=d
 tool=makeid { IN} { OUT}
 
 The problem should also extend to any rule that doesn't create a 
 resource file but haven't verified that.
 
 A quick fix would be to add a check in ProcessExternal() to only pass 
 files with the extension ".RES" to AddLink().


Damn! That was on my TODO list and I forgot about it. Looking good for 3.01
;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
7/06/2006 9:52:29 AM
Jun 06 2006
prev sibling next sibling parent reply Frank Benoit <keinfarbton nospam.xyz> writes:
Derek Parnell schrieb:

 The next release of Build is now available. 
 
 See http://www.dsource.org/projects/build/wiki for more details.
 


Thanks for your work.

And a first bug report on Linux building a lib
If i give the option -UMB=No or not, all *.o are created in the actual
directory. Later ar complains about missing <path to source files>/mod.o
files.
If i give the option -UMB=Yes, all *.o with the same name, but from
different packages overwrite each other.
I tried the '-test' option. Here it seams to be ok, no '-od' is in the
command.
The same build succeeds with build 2.09 and the same dmd 0.160

A typo in the documentation: the option is called UBM (title) instead of
UMB.
Jun 06 2006
parent Derek Parnell <derek psych.ward> writes:
On Tue, 06 Jun 2006 18:41:29 +0200, Frank Benoit wrote:


 Derek Parnell schrieb:

 The next release of Build is now available. 
 
 See http://www.dsource.org/projects/build/wiki for more details.
 


 
 Thanks for your work.
 
 And a first bug report on Linux building a lib
 If i give the option -UMB=No or not, all *.o are created in the actual
 directory. 


Yep. That would be expected. Without this switch set to YES, the .o file is
created in the same directory as the respective source file.


 Later ar complains about missing <path to source files>/mod.o files.


Are you saying that the .o files have been moved or deleted before 'ar'
gets to run? Where are the .o files now? 


 If i give the option -UMB=Yes, all *.o with the same name, but from
 different packages overwrite each other.


Yep. That would be expected. With -UMB=YES, all .o files are created in the
current directory.


 I tried the '-test' option. Here it seams to be ok, no '-od' is in the
 command.
 The same build succeeds with build 2.09 and the same dmd 0.160


What are you expecting to happen with respect to .o file creation? 


 A typo in the documentation: the option is called UBM (title) instead of
 UMB.


Thanks.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
7/06/2006 9:55:34 AM
Jun 06 2006
prev sibling parent dickl <dick221z yahoo.com> writes:
Derek Parnell wrote:

 The next release of Build is now available. 
 
 See http://www.dsource.org/projects/build/wiki for more details.
 


For some strange reason, the linker doesn't properly create the 
executable when /noi/map are on their own line. The executable comes out 
a few hundred bytes smaller and the executable acts nothing short of weird.

The fix seems to be writing the .KSP file like this

foo.obj
foo.exe
foo.map
kernel32.lib+user32.lib
foo.def
foo.res/noi/map

I think that's the last of problems...

Great program... saves me a whole lotta work!
Dick
Jun 06 2006