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

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

[Eli Zaretskii]

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?

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

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

[Andrew Cagney]

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 :-)

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

[Eli Zaretskii]

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

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

[Eli Zaretskii]

> Date: Fri, 23 Mar 2001 20:33:26 -0500
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> > Actually, it _can_ be upper-case, just not all of it.  VERSION.in or
> > VERSION.txt should work, for example.
> 
> Ok if I just go with ``version''?

Yes.

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

[Andrew Cagney]

> FYI,  I'm about to check in the below but with s/VERSION/version/ for the file.
> 
> Anyone like to come up with a 5 line /bin/sh script that updates this file using CVS.  It would need to remember to use date -u and should probably check that it hasn't already been run today (1).  The path to the CVS repository and the path to the file would be arguments.
> 
> 
>     Andrew
> 
> (1) Due to the timezone scrample and the possibility of the CVS server going down, I'm thinking of cheating and running the cronjob twice (if not more :-)
> 
> 2001-03-17  Andrew Cagney  <ac131313@redhat.com>
> 
> * Makefile.in (VERSION): Delete.  Moved to file VERSION.
>     (version.c): Depends on file VERSION.  Extract version number from
>     VERSION file.
>     * VERSION: New file.
Not quite.

If the file is called ``version'' then make gets to smart for its self 
and thinks it knows how to build ``version'' from ``version.c'' ...

I'm now trying version.in.

	Andrew

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

[Eli Zaretskii]

On Sat, 17 Mar 2001, Andrew Cagney wrote:

> Per discussion on the gdb@ list, this patch moves GDB's version number
> out of Makefile.in and into a separate file called (of all things :-)
> VERSION.

This will get us back into the nuisance we had with COPYING and
copying.c, due to the file-name letter-case nuisance on DOS/Windows
file systems.  See this ChangeLog entry:

  2000-04-03  Eli Zaretskii  <eliz@is.elta.co.il>

          * Makefile.in (copying.c): Depend on copying.txt, not COPYING.
          (copying.txt): New target, a link to COPYING.

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.

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

[Andrew Cagney]

Hello,

Per discussion on the gdb@ list, this patch moves GDB's version number
out of Makefile.in and into a separate file called (of all things :-)
VERSION.

The intention is that this patch will be followed by two further
changes:

	o	a cronjob to update the date in
		the VERSION file.

	o	Replace 5.0 with a date

thoughts?

	Andrew
2001-03-17  Andrew Cagney  <ac131313@redhat.com>

	* Makefile.in (VERSION): Delete.  Moved to file VERSION.
	(version.c): Depends on file VERSION.  Extract version number from
	VERSION file.
	* VERSION: New file.
	
*** GDB/src/gdb/Makefile.in	Mon Mar 12 11:01:13 2001
--- WIP/src/gdb/Makefile.in	Sat Mar 17 14:54:35 2001
***************
*** 357,363 ****
  ADD_FILES = $(REGEX) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
  ADD_DEPS = $(REGEX) $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
  
- VERSION = 5.0
  DIST=gdb
  
  LINT=/usr/5bin/lint
--- 357,362 ----
***************
*** 1009,1018 ****
  		< $(srcdir)/COPYING > $(srcdir)/copying.tmp
  	mv $(srcdir)/copying.tmp $(srcdir)/copying.c
  
! version.c: Makefile
  	rm -f version.c
  	echo '#include "version.h"' >> version.c
! 	echo 'const char version[] = "$(VERSION)";' >> version.c
  	echo 'const char host_name[] = "$(host_alias)";' >> version.c
  	echo 'const char target_name[] = "$(target_alias)";' >> version.c
  version.o: version.c $(version_h)
--- 1008,1017 ----
  		< $(srcdir)/COPYING > $(srcdir)/copying.tmp
  	mv $(srcdir)/copying.tmp $(srcdir)/copying.c
  
! version.c: Makefile VERSION
  	rm -f version.c
  	echo '#include "version.h"' >> version.c
! 	echo 'const char version[] = "'"`head -1 ${srcdir}/VERSION`"'";' >> version.c
  	echo 'const char host_name[] = "$(host_alias)";' >> version.c
  	echo 'const char target_name[] = "$(target_alias)";' >> version.c
  version.o: version.c $(version_h)
*** GDB/src/gdb/VERSION	Wed Dec 31 19:00:00 1969
--- WIP/src/gdb/VERSION	Sat Mar 17 14:26:39 2001
***************
*** 0 ****
--- 1 ----
+ 5.0
From ac131313@cygnus.com Sun Mar 18 14:18:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>, GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfa/pascal!] Gag -Werror shift warning and bug
Date: Sun, 18 Mar 2001 14:18:00 -0000
Message-id: <3AB3CF5C.933413E1@cygnus.com>
References: <4.2.0.58.20010305095243.00c45b00@ics.u-strasbg.fr>
X-SW-Source: 2001-03/msg00338.html
Content-length: 1326

Pierre Muller wrote:
> 
> After looking at the c-exp.y equivalent code, I suggest that you simply
> take that code,
> as it doesn't seem to suffer from the same problems

Good point.  I'll check in the attatched.

	thanks, Andrew
2001-03-17  Andrew Cagney  <ac131313@redhat.com>

	* p-exp.y (parse_number): Avoid shift overflow when ``long''.
	Code copied from c-exp.y.

*** GDB/src/gdb/p-exp.y	Tue Mar  6 10:38:28 2001
--- WIP/src/gdb/p-exp.y	Sat Mar 17 15:46:29 2001
***************
*** 858,871 ****
      }
    else
      {
!       high_bit = (((ULONGEST)1)
! 		  << (TARGET_LONG_LONG_BIT - 32 - 1)
! 		  << 16
! 		  << 16);
!       if (high_bit == 0)
  	/* A long long does not fit in a LONGEST.  */
! 	high_bit =
! 	  (ULONGEST)1 << (sizeof (LONGEST) * HOST_CHAR_BIT - 1);
        unsigned_type = builtin_type_unsigned_long_long;
        signed_type = builtin_type_long_long;
      }
--- 858,870 ----
      }
    else
      {
!       int shift;
!       if (sizeof (ULONGEST) * HOST_CHAR_BIT < TARGET_LONG_LONG_BIT)
  	/* A long long does not fit in a LONGEST.  */
! 	shift = (sizeof (ULONGEST) * HOST_CHAR_BIT - 1);
!       else
! 	shift = (TARGET_LONG_LONG_BIT - 1);
!       high_bit = (ULONGEST) 1 << shift;
        unsigned_type = builtin_type_unsigned_long_long;
        signed_type = builtin_type_long_long;
      }
From kettenis@wins.uva.nl Sun Mar 18 15:59:00 2001
From: Mark Kettenis <kettenis@wins.uva.nl>
To: eliz@is.elta.co.il
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] Unified watchpoints for x86 platforms
Date: Sun, 18 Mar 2001 15:59:00 -0000
Message-id: <200103182306.f2IN6Fv00262@delius.kettenis.local>
References: <Pine.SUN.3.91.1010318105507.11615B-100000@is>
X-SW-Source: 2001-03/msg00339.html
Content-length: 995

   Date: Sun, 18 Mar 2001 10:56:25 +0200 (IST)
   From: Eli Zaretskii <eliz@is.elta.co.il>

   On Sat, 17 Mar 2001, Mark Kettenis wrote:

   > ... config/i386/nm-i386v.h is really for System V-ish systems only,
   > and not a generic i386 file (the comment on the first line of that
   > file is a misleading).

   Not only is the comment misleading, but it looks like all the x86
   targets include nm-i386v.h, so it is definitely used like a generic
   i386 file!

What makes you think that?  I see:

$ grep nm-i386v.h config/i386/*.h
config/i386/nm-go32.h:#include "i386/nm-i386v.h"
config/i386/nm-linux.h:#include "i386/nm-i386v.h"

Linux is a bit System V-ish, but DJGPP most certainly isn't, and in
principle it shouldn't include nm-i386v.h.  None of the other x86
targets include nm-i386v.h.

   > Therefore I think it's best to create a new config/i386/nm-i386.h
   > file and put your stuff there instead.

   Should I make nm-i386v.h include nm-i386.h, then?

I don't think so.

Mark