[rfc] Move Makefile.in:VERSION to VERSION file

Andrew Cagney ac131313@cygnus.com
Mon Mar 19 10:05:00 GMT 2001

Eli Zaretskii wrote:
> On Mon, 19 Mar 2001, Andrew Cagney wrote:
> > > Can we have a different name, please?  Why can't we have version.c in
> > > the first place, without any intermediaries?  COPYING was an external
> > > file, but VERSION is not, I believe.
> >
> > I thought about that.  The reasons I created a separate file containing
> > just the version, rather than putting it in version.c, were two fold:
> >
> >       o       keep it completly separate
> >               from the source
> >
> >       o       make the update process as
> >               robust (mindless) as possible.
> I must be missing something, because I don't see how these two goals
> contradict what I suggested.  Why is it okay to edit a file called
> VERSION by hand, but not a file called version.c?
> Also, how about if you put the version string into Makefile.in (as a
> Make variable), and have Sed create version.c using that variable?

That is how things currently work :-)

The intention is that a nightly (1) cronjob would update the VERSION
number with the new days date.  Each update would involve a CVS commit.
If the VERSION is sitting in a file like Makefile.in (or to a lesser
extent version.c) that file's CVS log will slowly drown in those CVS

By creating a separate file that contains just the version number that
problem can be avoided.  It makes the update process really easy and
insulates the crontjob from any changes to how version.c is created. 
(Well that is the theory :-)

> > What exactly is the restriction on the filenames?  ``VERSION'' is a
> > fairly natural place to put a version number.
> The restriction is ``complicated'', as they say ;-).  But if you call the
> file just ``version'' (lower case) or ``version.in'', it will work.

I can probably live with that.  If I'm remembering right (ulgh, it is
all comming back), it can't be upper case (even if there isn't a
version.c) since the make dependencies get really messed up.


(1) That would be late afteroon for the geographically impaired :-)

More information about the Gdb-patches mailing list