Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfc] Move Makefile.in:VERSION to VERSION file
Date: Mon, 19 Mar 2001 10:05:00 -0000	[thread overview]
Message-ID: <3AB64A56.AFC28AFC@cygnus.com> (raw)
In-Reply-To: <Pine.SUN.3.91.1010319191131.25723C-100000@is>

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
commits.

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.

	Andrew

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


  reply	other threads:[~2001-03-19 10:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3AB62D06.55308D3A@cygnus.com>
2001-03-19  9:20 ` Eli Zaretskii
2001-03-19 10:05   ` Andrew Cagney [this message]
2001-03-19 11:54     ` Eli Zaretskii
     [not found]       ` <3ABBF966.A0155703@cygnus.com>
2001-03-23 23:58         ` Eli Zaretskii
2001-03-18 14:18 Andrew Cagney
2001-03-18 23:39 ` Eli Zaretskii
     [not found] ` <3AFB1C97.30009@cygnus.com>
2001-05-10 18:26   ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3AB64A56.AFC28AFC@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=eliz@is.elta.co.il \
    --cc=gdb-patches@sourceware.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox