This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfc] Move Makefile.in:VERSION to VERSION file
- To: ac131313 at cygnus dot com
- Subject: Re: [rfc] Move Makefile.in:VERSION to VERSION file
- From: Eli Zaretskii <eliz at delorie dot com>
- Date: Mon, 19 Mar 2001 14:54:10 -0500 (EST)
- CC: gdb-patches at sourceware dot cygnus dot com
- References: <Pine.SUN.3.91.1010319191131.25723C-100000@is> <3AB64A56.AFC28AFC@cygnus.com>
- Reply-to: Eli Zaretskii <eliz at is dot elta dot co dot il>
> Date: Mon, 19 Mar 2001 13:05:10 -0500
> From: Andrew Cagney <ac131313@cygnus.com>
>
> 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
> commits.
How about using an include directive in the Makefile, so that the
actual variable assignment could be on a separate file? Or you could
say something like "VERSION=`cat VERSION`", with a similar effect.
These both will work with DJGPP.
> 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.
Yet another idea is to have the cron job create version.c directly.
After all, it's not much larger than VERSION.
> > 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.
Actually, it _can_ be upper-case, just not all of it. VERSION.in or
VERSION.txt should work, for example.