Jump to page: 1 2
Thread overview
Build v2.00
Apr 08, 2005
Derek Parnell
Apr 08, 2005
jicman
Apr 08, 2005
Derek Parnell
Apr 08, 2005
jicman
Apr 08, 2005
clayasaurus
Apr 08, 2005
Derek Parnell
Apr 08, 2005
jicman
Apr 08, 2005
clayasaurus
Apr 09, 2005
Dejan Lekic
Feature request
Apr 09, 2005
Andrew Fedoniouk
Apr 11, 2005
zwang
Apr 11, 2005
Brad Anderson
April 08, 2005
The Build utility has reached a level of stability that I'm now calling it
version 2.00(.700)

You can get it from

 http://www.dsource.org/projects/build/

The next major enhancements are expected to include ...

** support for macro preprocessors
** building multiple applications in one invocation.
** building multiple editions of an application in one invocation.

-- 
Derek Parnell
Melbourne, Australia
http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage
8/04/2005 12:23:00 PM
April 08, 2005

Derek Parnell says...
>
>The Build utility has reached a level of stability that I'm now calling it
>version 2.00(.700)

Here is the output that I get when I run build:

6:17:43.07>build
Path and Version : d:\bin\build.exe v1.20(700)
built on Fri Apr  8 11:43:17 2005

Is this correct?  Since you called it version 2.00(.700), it does not look the
same.  Of course, versioning is not my strength. :-)

Again, thanks for this utility!  It has saved my typing life inmensely!

josé


April 08, 2005
On Fri, 8 Apr 2005 04:16:41 +0000 (UTC), jicman wrote:

> Derek Parnell says...
>>
>>The Build utility has reached a level of stability that I'm now calling it
>>version 2.00(.700)
> 
> Here is the output that I get when I run build:
> 
> 6:17:43.07>build
> Path and Version : d:\bin\build.exe v1.20(700)
> built on Fri Apr  8 11:43:17 2005
> 
> Is this correct?  Since you called it version 2.00(.700), it does not look the
> same.  Of course, versioning is not my strength. :-)

No it wasn't correct. I compiled the executable before I updated the
version number. I've got the correct one uploaded now. The (.700) is just
the internal build number for the application. It gets automatically
updated whenever it generate a new executable for 'Build'.

> Again, thanks for this utility!  It has saved my typing life inmensely!

You're welcome. However, I made it for selfish reasons - I'm lazy. ;-)

-- 
Derek
Melbourne, Australia
8/04/2005 2:29:50 PM
April 08, 2005
Derek Parnell says...
>
>On Fri, 8 Apr 2005 04:16:41 +0000 (UTC), jicman wrote:
>
>> Derek Parnell says...
>>>
>>>The Build utility has reached a level of stability that I'm now calling it
>>>version 2.00(.700)
>> 
>> Here is the output that I get when I run build:
>> 
>> 6:17:43.07>build
>> Path and Version : d:\bin\build.exe v1.20(700)
>> built on Fri Apr  8 11:43:17 2005
>> 
>> Is this correct?  Since you called it version 2.00(.700), it does not look the
>> same.  Of course, versioning is not my strength. :-)
>
>No it wasn't correct. I compiled the executable before I updated the version number. I've got the correct one uploaded now. The (.700) is just the internal build number for the application. It gets automatically updated whenever it generate a new executable for 'Build'.

Yep.  Just downloaded it and it's now jicman approved. :-)

> 
>> Again, thanks for this utility!  It has saved my typing life inmensely!
>
>You're welcome. However, I made it for selfish reasons - I'm lazy. ;-)

My friend, I wouldn't call it lazy.  You are a great time saver.  You don't like to waste time typing lots of libraries when you could simply just write a program to do that job for you... yeah, that's it. ;-)

jic


April 08, 2005
Derek Parnell wrote:
> The Build utility has reached a level of stability that I'm now calling it
> version 2.00(.700)
> 
> You can get it from 
> 
>  http://www.dsource.org/projects/build/
> 
> The next major enhancements are expected to include ...
> 
> ** support for macro preprocessors
> ** building multiple applications in one invocation.
> ** building multiple editions of an application in one invocation.
> 

Nice, though I myself do not need so much extra functionality!

Maybe you can do some versioning in the code so when you compile build you can choose which features you want and don't want, as I assume the more features the longer it takes to execute the dependency trees etc?

maybe like...

version(BUILD_BASIC)
{
... basic version of build
}
version(BUILD_SWISSKNIFE)
{
... supports all the neat build only things like macros's and others
}






April 08, 2005
On Fri, 08 Apr 2005 13:42:03 -0400, clayasaurus wrote:

> Derek Parnell wrote:
>> The Build utility has reached a level of stability that I'm now calling it
>> version 2.00(.700)
>> 
>> You can get it from
>> 
>>  http://www.dsource.org/projects/build/
>> 
>> The next major enhancements are expected to include ...
>> 
>> ** support for macro preprocessors
>> ** building multiple applications in one invocation.
>> ** building multiple editions of an application in one invocation.
>> 
> 
> Nice, though I myself do not need so much extra functionality!
> 
> Maybe you can do some versioning in the code so when you compile build you can choose which features you want and don't want, as I assume the more features the longer it takes to execute the dependency trees etc?
> 
> maybe like...
> 
> version(BUILD_BASIC)
> {
> ... basic version of build
> }
> version(BUILD_SWISSKNIFE)
> {
> ... supports all the neat build only things like macros's and others
> }

Well, if it ever gets to be a problem I'll consider that. Currently, to do a full compile of the Mango library takes about 2-3 seconds, the Phobos library about the same. So I don't think that providing the enhancements mentioned above is really going to add anymore than a few milliseconds to it.

-- 
Derek Parnell
Melbourne, Australia
9/04/2005 6:41:23 AM
April 08, 2005
Derek Parnell says...
>
>On Fri, 08 Apr 2005 13:42:03 -0400, clayasaurus wrote:
>
>> Derek Parnell wrote:
>>> The Build utility has reached a level of stability that I'm now calling it
>>> version 2.00(.700)
>>> 
>>> You can get it from
>>> 
>>>  http://www.dsource.org/projects/build/
>>> 
>>> The next major enhancements are expected to include ...
>>> 
>>> ** support for macro preprocessors
>>> ** building multiple applications in one invocation.
>>> ** building multiple editions of an application in one invocation.
>>> 
>> 
>> Nice, though I myself do not need so much extra functionality!
>> 
>> Maybe you can do some versioning in the code so when you compile build you can choose which features you want and don't want, as I assume the more features the longer it takes to execute the dependency trees etc?
>> 
>> maybe like...
>> 
>> version(BUILD_BASIC)
>> {
>> ... basic version of build
>> }
>> version(BUILD_SWISSKNIFE)
>> {
>> ... supports all the neat build only things like macros's and others
>> }
>
>Well, if it ever gets to be a problem I'll consider that. Currently, to do a full compile of the Mango library takes about 2-3 seconds, the Phobos library about the same. So I don't think that providing the enhancements mentioned above is really going to add anymore than a few milliseconds to it.

That's funny... :-)


April 08, 2005
Derek Parnell wrote:
> On Fri, 08 Apr 2005 13:42:03 -0400, clayasaurus wrote:
> 
> 
>>Derek Parnell wrote:
>>
>>>The Build utility has reached a level of stability that I'm now calling it
>>>version 2.00(.700)
>>>
>>>You can get it from 
>>>
>>> http://www.dsource.org/projects/build/
>>>
>>>The next major enhancements are expected to include ...
>>>
>>>** support for macro preprocessors
>>>** building multiple applications in one invocation.
>>>** building multiple editions of an application in one invocation.
>>>
>>
>>Nice, though I myself do not need so much extra functionality!
>>
>>Maybe you can do some versioning in the code so when you compile build you can choose which features you want and don't want, as I assume the more features the longer it takes to execute the dependency trees etc?
>>
>>maybe like...
>>
>>version(BUILD_BASIC)
>>{
>>... basic version of build
>>}
>>version(BUILD_SWISSKNIFE)
>>{
>>... supports all the neat build only things like macros's and others
>>}
> 
> 
> Well, if it ever gets to be a problem I'll consider that. Currently, to do
> a full compile of the Mango library takes about 2-3 seconds, the Phobos
> library about the same. So I don't think that providing the enhancements
> mentioned above is really going to add anymore than a few milliseconds to
> it. 
> 

Forgive my ignorance, but now that I think about it, a feature should only make build run slower if you decide to use it with the -feature switch?

If yes, than I know upgrading won't hurt builds awesome performance :-)

April 09, 2005
Excellent!

Mr. Parnell, build is realy a great project.

I like Your coding style as well (no javaLikeMethodNames() ... :)
I'll recommend build to my friends as well, that's for sure!

Kind regards

Dejan

-- 
...........
Dejan Lekic
  http://dejan.lekic.org

April 09, 2005
To add import feature to be able to write
something like this:

static ubyte[] myBinResource = import@filename.ext;

Being preprocessed will generate

static ubyte[] myBinResource =
[
    0x01, 0x02, .... // all other bytes from filename.ext
]

Huh?






« First   ‹ Prev
1 2