www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - program software versions

reply jicman <jicman_member pathlink.com> writes:
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é
Mar 21 2005
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Mar 21 2005
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:

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?)
Mar 21 2005
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
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
Mar 21 2005
parent reply jicman <jicman_member pathlink.com> writes:
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!
Mar 21 2005
parent reply jicman <jicman_member pathlink.com> writes:
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
Mar 21 2005
parent reply Derek Parnell <derek psych.ward> writes:
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
Mar 21 2005
parent reply jicman <jicman_member pathlink.com> writes:
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.
Mar 21 2005
parent reply Derek Parnell <derek psych.ward> writes:
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
Mar 21 2005
parent jicman <jicman_member pathlink.com> writes:
Derek Parnell says...
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.
My code is right, but Windows is playing tricks on me. I don't think it's refreshing the file fast enough. I just tried it once and it failed. But I tried it again, and moved it again, and it worked. So, once again, my apologies. Ignore the post on the build forum. ;-) thanks. josé PS: Did I say that I love build? thanks. This utility rocks! Love it. One more question: what
Mar 21 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Mar 21 2005
parent jicman <jicman_member pathlink.com> writes:
Walter says...
"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.
And I thought you were busy... :-) Yes, I kinda figured that out, but that's too many steps. You coud also use the build utility and use auto_build_number and make your life so much easier. :-) thanks, though. josé
Mar 21 2005