Re: Creating build version numbers (was RE: How to always build a tar get?)

[Peter A. Vogel]

Why not just pass the version # as a define?  In my
build processes, the version number information is
encoded in the file tags.  So I look at what tag was
checked out, or what the last tag that exists on the
Makefile (or conscript, depending on where I am at
the moment :-) and derive the build number from that.

For nightly builds, the build number comes from the
tag information and the current date, ensuring that
there is always a unique version ID for every nightly
build and that it is recognizable as a nightly build as
opposed to a release build.

By doing it this way, I avoid a bazillion revisions of
a version.h file...

-Peter
----- Original Message -----
From: "Steven Knight" <address@hidden>
To: "Eric Brown" <address@hidden>
Cc: <address@hidden>
Sent: Monday, October 30, 2000 2:38 PM
Subject: Re: Creating build version numbers (was RE: How to always build a
tar get?)


> On Mon, 30 Oct 2000, Eric Brown wrote:
> > > Invoking something every time and letting the underlying tool handle
part
> > > of the dependency analysis runs counter to Cons' design.  Cons would
> > > have no way of knowing that your smart tool figured out that it didn't
> > > need to update the header file.  Hence, Cons would still think the
header
> > > file had been rebuilt every time, and it would then try to rebuild
every
> > > target that depends on that header file every time, which is probably
not
> > > what you want.  You could get around this by Ignore()ing the
dependency
> > > on the header file, but then the dependent targets wouldn't get
rebuilt
> > > when you actually wanted them to...
> >
> > OK.  What I really want is the header in question (which contains a
build
> > version number) to get rebuilt on the first build of the day (and not
> > thereafter).  Is there a good (or even feasible) way to do this?
>
> Heck, why not do it in straight Perl?  (The light bulb just came on...)
> Since you already have a tool to do this, you could just call system to
> do it:
>
> system("tool_to_update_version_number version_file.h");
>
> That way, Cons would be happy because it would simply detect the change
> to the contents of the version file and rebuild anything that includes
> it as appropriate.
>
> This would work because it keeps the separate "dependency" calculation
> (based on whether this is the first build of the day) outside of the Cons
> dependency tree.  The problem with trying to "build" the file every time
> through a Cons method like Command is that it mixes the two different
> dependency mechanisms, with unfortunate side effects...
>
> --SK
>
>
> _______________________________________________
> address@hidden
> http://mail.gnu.org/mailman/listinfo/cons-discuss
> Cons URL: http://www.dsmit.com/cons/