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

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().

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.

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

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

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