Greetings!

I have a program that I have a version that prints out when it's run, ie,

13:22:05.58>dmd
Digital Mars D Compiler v0.117
Copyright (c) 1999-2005 by Digital Mars written by Walter Bright
Documentation: www.digitalmars.com/d/index.html
Usage:
dmd files.d ... { -switch }
..
..

but I want this version to change when I compile the program.  I have an idea
how to do this, which involves scripting, but how do people out there do this
without scripting?  Is this hardcoded in the code?  How does Walter does this?
(Walter, please don't answer this.  It's just a question to the rest of the
folks, out there.)

thanks,

josé

jicman wrote:
> Greetings!
> 
> I have a program that I have a version that prints out when it's run, ie,
<snip>
> but I want this version to change when I compile the program.  I have an idea
> how to do this, which involves scripting, but how do people out there do this
> without scripting? 

By using a compiler that keeps track of the build number and provides a 
means of referring to this value in code.  I don't know of any language 
that has it as a standard feature.  (Does Visual Basic, for that matter?)

> Is this hardcoded in the code?  How does Walter does this?
> (Walter, please don't answer this.  It's just a question to the rest of the
> folks, out there.)

I imagine that Walter compiles several builds on his machine between 
release versions.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.

Actually, I'm pretty sure that Visual Studio .NET *does* do this for C#, 
at least.

You could theoretically use __TIMESTAMP__...

-[Unknown]


> By using a compiler that keeps track of the build number and provides a 
> means of referring to this value in code.  I don't know of any language 
> that has it as a standard feature.  (Does Visual Basic, for that matter?)

In article <d1n3ne$fot$1@digitaldaemon.com>, jicman says...
>
>
>Greetings!
>
>I have a program that I have a version that prints out when it's run, ie,
>
>13:22:05.58>dmd
>Digital Mars D Compiler v0.117
>Copyright (c) 1999-2005 by Digital Mars written by Walter Bright
>Documentation: www.digitalmars.com/d/index.html
>Usage:
>dmd files.d ... { -switch }
>..
>..
>
>but I want this version to change when I compile the program.

The build utility has a feature that tracks build numbers automatically, so you
can use them in your code (http://www.dsource.org/projects/build/)

From the documentation:

> 
>  Example:
> If your module is called "parser.d" you would have the lines ...
> 
>   module parser;
>   private import parser_bn;
> 
> You can access the build number from within the module thus ...
> 
>           writefln("Build number is %d", auto_build_number);


- EricAnderton at yahoo

In article <d1n9rl$lp4$1@digitaldaemon.com>, pragma says...

>The build utility has a feature that tracks build numbers automatically, so you
>can use them in your code (http://www.dsource.org/projects/build/)
>
>From the documentation:
>
>> 
>>  Example:
>> If your module is called "parser.d" you would have the lines ...
>> 
>>   module parser;
>>   private import parser_bn;
>> 
>> You can access the build number from within the module thus ...
>> 
>>           writefln("Build number is %d", auto_build_number);

thanks.  This is exactly what I want!  This build utility rocks!

In article <d1nbht$nck$1@digitaldaemon.com>, jicman says...
>
>In article <d1n9rl$lp4$1@digitaldaemon.com>, pragma says...
>
>>The build utility has a feature that tracks build numbers automatically, so you
>>can use them in your code (http://www.dsource.org/projects/build/)
>>
>>From the documentation:
>>
>>> 
>>>  Example:
>>> If your module is called "parser.d" you would have the lines ...
>>> 
>>>   module parser;
>>>   private import parser_bn;
>>> 
>>> You can access the build number from within the module thus ...
>>> 
>>>           writefln("Build number is %d", auto_build_number);
>
>thanks.  This is exactly what I want!  This build utility rocks!

Ja ja ja!  (that's me, laughing in Spanish :-))  Anyway, spoke too soon.  If I
move the executable out of the build spot, the build number is gone.  It would
be nice if it could keep it, huh?  :-)

Ok, back to the drawing board.

thanks.

jic

On Mon, 21 Mar 2005 21:00:15 +0000 (UTC), jicman wrote:

> In article <d1nbht$nck$1@digitaldaemon.com>, jicman says...
>>
>>In article <d1n9rl$lp4$1@digitaldaemon.com>, pragma says...
>>
>>>The build utility has a feature that tracks build numbers automatically, so you
>>>can use them in your code (http://www.dsource.org/projects/build/)
>>>
>>>From the documentation:
>>>
>>>> 
>>>>  Example:
>>>> If your module is called "parser.d" you would have the lines ...
>>>> 
>>>>   module parser;
>>>>   private import parser_bn;
>>>> 
>>>> You can access the build number from within the module thus ...
>>>> 
>>>>           writefln("Build number is %d", auto_build_number);
>>
>>thanks.  This is exactly what I want!  This build utility rocks!
> 
> Ja ja ja!  (that's me, laughing in Spanish :-))  Anyway, spoke too soon.  If I
> move the executable out of the build spot, the build number is gone.  It would
> be nice if it could keep it, huh?  :-)

???? What do you mean by "move the executable out of the build spot"?

I've been using it for a while now with no problems. And I don't have the
executable in the same directory as the source code. 

-- 
Derek Parnell
Melbourne, Australia
22/03/2005 8:32:30 AM

In article <1qdx8l6u76mg3.4s0jzjz7cfv2.dlg@40tude.net>, Derek Parnell says...
>
>On Mon, 21 Mar 2005 21:00:15 +0000 (UTC), jicman wrote:
>
>> In article <d1nbht$nck$1@digitaldaemon.com>, jicman says...
>>>
>>>In article <d1n9rl$lp4$1@digitaldaemon.com>, pragma says...
>>>
>>>>The build utility has a feature that tracks build numbers automatically, so you
>>>>can use them in your code (http://www.dsource.org/projects/build/)
>>>>
>>>>From the documentation:
>>>>
>>>>> 
>>>>>  Example:
>>>>> If your module is called "parser.d" you would have the lines ...
>>>>> 
>>>>>   module parser;
>>>>>   private import parser_bn;
>>>>> 
>>>>> You can access the build number from within the module thus ...
>>>>> 
>>>>>           writefln("Build number is %d", auto_build_number);
>>>
>>>thanks.  This is exactly what I want!  This build utility rocks!
>> 
>> Ja ja ja!  (that's me, laughing in Spanish :-))  Anyway, spoke too soon.  If I
>> move the executable out of the build spot, the build number is gone.  It would
>> be nice if it could keep it, huh?  :-)
>
>???? What do you mean by "move the executable out of the build spot"?
>
>I've been using it for a while now with no problems. And I don't have the
>executable in the same directory as the source code. 

Let's say that I build a program from a prog.d file on

d:\progs\d

then I take newly built prog.exe and I move it to c:\

If I run it there, the value that I get for auto_build_number is 0.  So, my
program now shows,

version: 1.1.0

instead of

version: 1.1.22

which was the build version on

d:\progs\d

Or, is this suppose to work?  Because, since you know my history (;-)) I have
made a few mistakes with build. :-)  So, I checked it three times to make sure.
Are you inserting the auto_build_number value into the program itself?

thanks.

On Mon, 21 Mar 2005 21:50:45 +0000 (UTC), jicman wrote:

> In article <1qdx8l6u76mg3.4s0jzjz7cfv2.dlg@40tude.net>, Derek Parnell says...
>>
>>On Mon, 21 Mar 2005 21:00:15 +0000 (UTC), jicman wrote:
>>
>>> In article <d1nbht$nck$1@digitaldaemon.com>, jicman says...
>>>>
>>>>In article <d1n9rl$lp4$1@digitaldaemon.com>, pragma says...
>>>>
>>>>>The build utility has a feature that tracks build numbers automatically, so you
>>>>>can use them in your code (http://www.dsource.org/projects/build/)
>>>>>
>>>>>From the documentation:
>>>>>
>>>>>> 
>>>>>>  Example:
>>>>>> If your module is called "parser.d" you would have the lines ...
>>>>>> 
>>>>>>   module parser;
>>>>>>   private import parser_bn;
>>>>>> 
>>>>>> You can access the build number from within the module thus ...
>>>>>> 
>>>>>>           writefln("Build number is %d", auto_build_number);
>>>>
>>>>thanks.  This is exactly what I want!  This build utility rocks!
>>> 
>>> Ja ja ja!  (that's me, laughing in Spanish :-))  Anyway, spoke too soon.  If I
>>> move the executable out of the build spot, the build number is gone.  It would
>>> be nice if it could keep it, huh?  :-)
>>
>>???? What do you mean by "move the executable out of the build spot"?
>>
>>I've been using it for a while now with no problems. And I don't have the
>>executable in the same directory as the source code. 
> 
> Let's say that I build a program from a prog.d file on
> 
> d:\progs\d
> 
> then I take newly built prog.exe and I move it to c:\
> 
> If I run it there, the value that I get for auto_build_number is 0.  So, my
> program now shows,
> 
> version: 1.1.0
> 
> instead of
> 
> version: 1.1.22
> 
> which was the build version on
> 
> d:\progs\d
> 
> Or, is this suppose to work?  Because, since you know my history (;-)) I have
> made a few mistakes with build. :-)  So, I checked it three times to make sure.
> Are you inserting the auto_build_number value into the program itself?

Weird! This is exactly what I do too. I use build with my source in 
 f:\projects\d_proj\build\trunk\source\

and move the resulting executable to 
 d:\util\

An the build number does not change.

Ok, this is how it works...

When Build sees the construct "private import <modname>_bn;" it looks for a
file called <modname>_bn.d and if it doesn't exist it creates one that
looks like ...

 module <modname>_bn;
 // This file is automatically maintained by the BUILD utility,
 // Please refrain from manually editing it.
 long auto_build_number = 1;

If how ever the file does exist, Build reads it in, increments the value of
auto_build_number and writes the file back out again.

All that is done *before* it calls DMD to compile it. Thus when DMD gets
hold of the <modname>.d file, DMD imports the updated build number and
compiles that into the executable file. So moving the executable does not
change or reset the build number.

If you ever move the <modname>.d file, you should also move its
<modname>_bn.d file so as to keep the same sequence going, otherwise the
sequence is reset to 1 again.

And thinking of that, the value of auto_build_number is never zero, as it
starts at one. Can you show me the code that displays the version and build
number? Here is what I use ...

   module build;
   private import build_bn;
   . . .[snipped lines]. . .
   writefln(
       "Path and Version : %s v%s(%d)\n  built on %s"
           ,vAppPath, vAppVersion, build_bn.auto_build_number,
           __TIMESTAMP__);

Hope this helps.
-- 
Derek Parnell
Melbourne, Australia
22/03/2005 8:58:45 AM

"jicman" <jicman_member@pathlink.com> wrote in message
news:d1n3ne$fot$1@digitaldaemon.com...
> I have a program that I have a version that prints out when it's run, ie,
> [...]
> but I want this version to change when I compile the program.  I have an
idea
> how to do this, which involves scripting, but how do people out there do
this
> without scripting?  Is this hardcoded in the code?  How does Walter does
this?
> (Walter, please don't answer this.  It's just a question to the rest of
the
> folks, out there.)

I'll answer it anyway <g>. It's a common problem. An easy way to handle it
is to write a D program that reads a file that contains the current build
number, increments the build number, then writes that file back out again.
Then, that program writes a little .d module that is simply:

   int buildversion = nnnn;

where nnnn is the number from the file. Then, the application compiles and
links in that little .d module. It sounds complicated, but when set up right
in the makefile it works well.