FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

inserting the auto_build_number value into a program

 
Post new topic   Reply to topic     Forum Index -> Build
View previous topic :: View next topic  
Author Message
jicman



Joined: 22 Dec 2004
Posts: 298
Location: Rochester, NY

PostPosted: Mon Mar 21, 2005 3:22 pm    Post subject: inserting the auto_build_number value into a program Reply with quote

Greetings mate! :-)

I am trying to keep versions of the software programs that I create by using some inside values in my programs. the problem is that I need to keep editing the programs every time I make a change before compile time. So, someone suggested the auto_build_number, which works wonder, by the way! But, when I take out that executable out of the build directory, that value, which I love, was taken out. Of course! :-)

So, the idea would be that build would insert that value into the program, itself. Maybe by a private import of a module, which you would handle at compile time.

I have an idea how I can do it, but I don't want to build my own build utility, after you have done such a wonderful job with it. Any thoughts?

thanks.

jic
Back to top
View user's profile Send private message
Derek Parnell



Joined: 22 Apr 2004
Posts: 408
Location: Melbourne, Australia

PostPosted: Mon Mar 21, 2005 4:40 pm    Post subject: Re: inserting the auto_build_number value into a program Reply with quote

jicman wrote:
Greetings mate! Smile

I am trying to keep versions of the software programs that I create by using some inside values in my programs. the problem is that I need to keep editing the programs every time I make a change before compile time. So, someone suggested the auto_build_number, which works wonder, by the way! But, when I take out that executable out of the build directory, that value, which I love, was taken out. Of course! Smile

So, the idea would be that build would insert that value into the program, itself. Maybe by a private import of a module, which you would handle at compile time.

I have an idea how I can do it, but I don't want to build my own build utility, after you have done such a wonderful job with it. Any thoughts?

thanks.

jic

This is exactly what I do too. I use build with my source in

Code:
f:\projects\d_proj\build\trunk\source\


and move the resulting executable to

Code:
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 ...

Code:
  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 ...

Code:
    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
skype name: derek.j.parnell
Back to top
View user's profile Send private message
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Mon Mar 21, 2005 10:26 pm    Post subject: Reply with quote

This is a very, very cool feature. But, I do have an idea that might potentially improve it slightly. How about changing the convention from:
Code:

  private import thismodule_bn;
  // ...
  appversion.build = auto_build_number;


To something more like this, which would be consistent with Build's other features:
Code:

  // build number -- 0.1.* -- modified 2005-03-21
  pragma(buildnumber) const long buildNumber = 0;


This has a couple of niceties. For one, it means not having to invent a whole other module for the build number, thereby potentially depriving some projects of a name (though one wonders what need there'd be for "_bn" modules). For another, it is more consistant with Build's other features in using pragma() to communicate. For a third, it lets the developer use whatever name they want for the build number constant, and to easily reset it for new versions.

Thoughts?
Could always support both formats and have a command line switch or something to force the "import *_bn;" style to be ignored? I dunno.
_________________
Chris Nicholson-Sauls
Back to top
View user's profile Send private message AIM Address Yahoo Messenger
Derek Parnell



Joined: 22 Apr 2004
Posts: 408
Location: Melbourne, Australia

PostPosted: Mon Mar 21, 2005 11:06 pm    Post subject: Reply with quote

csauls wrote:
This is a very, very cool feature. But, I do have an idea that might potentially improve it slightly. How about changing the convention from:
Code:

  private import thismodule_bn;
  // ...
  appversion.build = auto_build_number;


To something more like this, which would be consistent with Build's other features:
Code:

  // build number -- 0.1.* -- modified 2005-03-21
  pragma(buildnumber) const long buildNumber = 0;


This has a couple of niceties. For one, it means not having to invent a whole other module for the build number, thereby potentially depriving some projects of a name (though one wonders what need there'd be for "_bn" modules). For another, it is more consistant with Build's other features in using pragma() to communicate. For a third, it lets the developer use whatever name they want for the build number constant, and to easily reset it for new versions.

Thoughts?
Could always support both formats and have a command line switch or something to force the "import *_bn;" style to be ignored? I dunno.


This is in fact how I first designed it. But then I came up to a few of D's little gotchas.

Consider the situation where you had
Code:
 pragma(buildnumber) const long buildNumber = 9;

in your source code file, say called "mymodule.d". For that build number to increment, my Build would have to change the source code of "mymodule.d" to
Code:
 pragma(buildnumber) const long buildNumber = 10;

To do that, I would have to rename the original file, to say "temp.xxx", and then copy over all the lines except this one, as I'd be substituting it with an updated pragma line, then delete the copy. This has a few problems. Firstly, the pragma can occur anywhere in the code, so it could be that I only find the pragma after I'd processed most of the file. So I'd have to remember where I'm up to, do the rename/copy bit, resyncronize where I was up to ('cos the update could expand the line) and then continue. Secondly, there is nothing stopping the coder from putting in multiple pragma(buildnumber) statements. Thirdly, a pragma can extend over multiple source lines and still be syntactially correct, so this add complexity. Forthly, and this is the killer, to get DMD to ignore this pragma, (and you have to do this because DMD doesn't know about it) you need to place it inside a version statement.
Code:
version(build) pragma(buildnumber) const int BN = 0;

But now, how does your application access the BN identifier?
It is only compiled if version(build) is set on, but if that is set then DMD complains that it doesn't understand pragma(buildnumber)!

So the upshot is that its easier to import a module that Build manages.

However, a future release of Build is going to support a form of preprocessor, so maybe we can use something like this eventually.
_________________
--
Derek
skype name: derek.j.parnell
Back to top
View user's profile Send private message
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Tue Mar 22, 2005 12:31 pm    Post subject: Reply with quote

You make a good point. One could always slap an array of restrictions on it, but then it'd just be hassle for everyone involved. So, yeah. Will keep an eye out for that "preprocessor" of yours, though.
_________________
Chris Nicholson-Sauls
Back to top
View user's profile Send private message AIM Address Yahoo Messenger
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Build All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group