My patch for GCC 5 directory names

My patch for GCC 5 directory names

[Richard Biener]

I promised to send out my pat^Whack.  Before building I introduce
gcc/FULL-VER as copy of gcc/BASE-VER and adjust gcc/BASE-VER to
just the major number.  Then I only need the following small
patch (where I don't speak enough tcl for fixing libjava.exp "properly").

Without the FULL-VER trick the patch would be much larger (BASE-VER
is referenced a lot).  For a "real" patch (including configury) we
probably want to generate a BASE-VER in the toplevel (or have
a @BASE-VER@ substitute).

Richard.

Index: gcc/Makefile.in
===================================================================
--- gcc/Makefile.in.orig	2015-05-08 17:10:12.068697540 +0200
+++ gcc/Makefile.in	2015-05-08 17:25:31.831833081 +0200
@@ -810,12 +810,14 @@ GTM_H     = tm.h      $(tm_file_list) in
 TM_H      = $(GTM_H) insn-flags.h $(OPTIONS_H)
 
 # Variables for version information.
-BASEVER     := $(srcdir)/BASE-VER  # 4.x.y
+BASEVER     := $(srcdir)/BASE-VER  # 5
+FULLVER     := $(srcdir)/FULL-VER  # 5.x.y
 DEVPHASE    := $(srcdir)/DEV-PHASE # experimental, prerelease, ""
 DATESTAMP   := $(srcdir)/DATESTAMP # YYYYMMDD or empty
 REVISION    := $(srcdir)/REVISION  # [BRANCH revision XXXXXX]
 
 BASEVER_c   := $(shell cat $(BASEVER))
+FULLVER_c   := $(shell cat $(FULLVER))
 DEVPHASE_c  := $(shell cat $(DEVPHASE))
 DATESTAMP_c := $(shell cat $(DATESTAMP))
 
@@ -839,6 +841,7 @@ PATCHLEVEL_c := \
 # immediately after the comma in the $(if ...) constructs is
 # significant - do not remove it.
 BASEVER_s   := "\"$(BASEVER_c)\""
+FULLVER_s   := "\"$(FULLVER_c)\""
 DEVPHASE_s  := "\"$(if $(DEVPHASE_c), ($(DEVPHASE_c)))\""
 DATESTAMP_s := \
   "\"$(if $(DEVPHASE_c)$(filter-out 0,$(PATCHLEVEL_c)), $(DATESTAMP_c))\""
@@ -2028,7 +2031,7 @@ s-options-h: optionlist $(srcdir)/opt-fu
 
 dumpvers: dumpvers.c
 
-CFLAGS-version.o += -DBASEVER=$(BASEVER_s) -DDATESTAMP=$(DATESTAMP_s) \
+CFLAGS-version.o += -DBASEVER=$(FULLVER_s) -DDATESTAMP=$(DATESTAMP_s) \
 	-DREVISION=$(REVISION_s) \
 	-DDEVPHASE=$(DEVPHASE_s) -DPKGVERSION=$(PKGVERSION_s) \
 	-DBUGURL=$(BUGURL_s)
@@ -2038,10 +2041,10 @@ version.o: $(REVISION) $(DATESTAMP) $(BA
 CFLAGS-lto-compress.o += $(ZLIBINC)
 
 bversion.h: s-bversion; @true
-s-bversion: BASE-VER
-	echo "#define BUILDING_GCC_MAJOR `echo $(BASEVER_c) | sed -e 's/^\([0-9]*\).*$$/\1/'`" > bversion.h
-	echo "#define BUILDING_GCC_MINOR `echo $(BASEVER_c) | sed -e 's/^[0-9]*\.\([0-9]*\).*$$/\1/'`" >> bversion.h
-	echo "#define BUILDING_GCC_PATCHLEVEL `echo $(BASEVER_c) | sed -e 's/^[0-9]*\.[0-9]*\.\([0-9]*\)$$/\1/'`" >> bversion.h
+s-bversion: FULL-VER
+	echo "#define BUILDING_GCC_MAJOR `echo $(FULLVER_c) | sed -e 's/^\([0-9]*\).*$$/\1/'`" > bversion.h
+	echo "#define BUILDING_GCC_MINOR `echo $(FULLVER_c) | sed -e 's/^[0-9]*\.\([0-9]*\).*$$/\1/'`" >> bversion.h
+	echo "#define BUILDING_GCC_PATCHLEVEL `echo $(FULLVER_c) | sed -e 's/^[0-9]*\.[0-9]*\.\([0-9]*\)$$/\1/'`" >> bversion.h
 	echo "#define BUILDING_GCC_VERSION (BUILDING_GCC_MAJOR * 1000 + BUILDING_GCC_MINOR)" >> bversion.h
 	$(STAMP) s-bversion
 
@@ -2410,9 +2413,9 @@ build/%.o :  # dependencies provided by
 ## build/version.o is compiled by the $(COMPILER_FOR_BUILD) but needs
 ## several C macro definitions, just like version.o
 build/version.o:  version.c version.h \
-                  $(REVISION) $(DATESTAMP) $(BASEVER) $(DEVPHASE)
+                  $(REVISION) $(DATESTAMP) $(FULLVER) $(DEVPHASE)
 	$(COMPILER_FOR_BUILD) -c $(BUILD_COMPILERFLAGS) $(BUILD_CPPFLAGS) \
-	-DBASEVER=$(BASEVER_s) -DDATESTAMP=$(DATESTAMP_s) \
+	-DBASEVER=$(FULLVER_s) -DDATESTAMP=$(DATESTAMP_s) \
 	-DREVISION=$(REVISION_s) \
 	-DDEVPHASE=$(DEVPHASE_s) -DPKGVERSION=$(PKGVERSION_s) \
 	-DBUGURL=$(BUGURL_s) -o $@ $<
@@ -2623,8 +2626,8 @@ PREPROCESSOR_DEFINES = \
   -DSTANDARD_EXEC_PREFIX=\"$(libdir)/gcc/\" \
   @TARGET_SYSTEM_ROOT_DEFINE@
 
-CFLAGS-cppbuiltin.o += $(PREPROCESSOR_DEFINES) -DBASEVER=$(BASEVER_s)
-cppbuiltin.o: $(BASEVER)
+CFLAGS-cppbuiltin.o += $(PREPROCESSOR_DEFINES) -DBASEVER=$(FULLVER_s)
+cppbuiltin.o: $(FULLVER)
 
 CFLAGS-cppdefault.o += $(PREPROCESSOR_DEFINES)
 
@@ -2640,8 +2643,8 @@ build/gcov-iov$(build_exeext): build/gco
 		build/gcov-iov.o -o $@
 
 gcov-iov.h: s-iov
-s-iov: build/gcov-iov$(build_exeext) $(BASEVER) $(DEVPHASE)
-	build/gcov-iov$(build_exeext) '$(BASEVER_c)' '$(DEVPHASE_c)' \
+s-iov: build/gcov-iov$(build_exeext) $(FULLVER) $(DEVPHASE)
+	build/gcov-iov$(build_exeext) '$(FULLVER_c)' '$(DEVPHASE_c)' \
 	    > tmp-gcov-iov.h
 	$(SHELL) $(srcdir)/../move-if-change tmp-gcov-iov.h gcov-iov.h
 	$(STAMP) s-iov
Index: libjava/testsuite/lib/libjava.exp
===================================================================
--- libjava/testsuite/lib/libjava.exp.orig	2014-12-02 13:29:22.487902351 +0100
+++ libjava/testsuite/lib/libjava.exp	2015-05-08 17:25:31.831833081 +0200
@@ -179,7 +179,7 @@ proc libjava_init { args } {
 
     set text [eval exec "$GCJ_UNDER_TEST -B$specdir -v 2>@ stdout"]
     regexp " version \[^\n\r\]*" $text version
-    set libjava_version [lindex $version 1]
+    set libjava_version 5
 
     verbose "version: $libjava_version"
 
Index: gcc/cppbuiltin.c
===================================================================
--- gcc/cppbuiltin.c.orig	2015-01-12 16:22:34.486893087 +0100
+++ gcc/cppbuiltin.c	2015-05-08 17:25:31.832833089 +0200
@@ -46,9 +46,9 @@ parse_basever (int *major, int *minor, i
   static int s_major = -1, s_minor, s_patchlevel;
 
   if (s_major == -1)
-    if (sscanf (BASEVER, "%d.%d.%d", &s_major, &s_minor, &s_patchlevel) != 3)
+    if (sscanf (version_string, "%d.%d.%d", &s_major, &s_minor, &s_patchlevel) != 3)
       {
-	sscanf (BASEVER, "%d.%d", &s_major, &s_minor);
+	sscanf (version_string, "%d.%d", &s_major, &s_minor);
 	s_patchlevel = 0;
       }
 

Re: My patch for GCC 5 directory names

[H.J. Lu]

On Tue, May 12, 2015 at 6:42 AM, Richard Biener <rguenther@suse.de> wrote:
>
> I promised to send out my pat^Whack.  Before building I introduce
> gcc/FULL-VER as copy of gcc/BASE-VER and adjust gcc/BASE-VER to
> just the major number.  Then I only need the following small
> patch (where I don't speak enough tcl for fixing libjava.exp "properly").
>
> Without the FULL-VER trick the patch would be much larger (BASE-VER
> is referenced a lot).  For a "real" patch (including configury) we
> probably want to generate a BASE-VER in the toplevel (or have
> a @BASE-VER@ substitute).
>

What is wrong to print "prerelease" with "gcc -v" on GCC 5 branch? If
it isn't a prerelease, what is it? And let's call it what it is.

-- 
H.J.

Re: My patch for GCC 5 directory names

[Richard Biener]

On Tue, 12 May 2015, H.J. Lu wrote:

> On Tue, May 12, 2015 at 6:42 AM, Richard Biener <rguenther@suse.de> wrote:
> >
> > I promised to send out my pat^Whack.  Before building I introduce
> > gcc/FULL-VER as copy of gcc/BASE-VER and adjust gcc/BASE-VER to
> > just the major number.  Then I only need the following small
> > patch (where I don't speak enough tcl for fixing libjava.exp "properly").
> >
> > Without the FULL-VER trick the patch would be much larger (BASE-VER
> > is referenced a lot).  For a "real" patch (including configury) we
> > probably want to generate a BASE-VER in the toplevel (or have
> > a @BASE-VER@ substitute).
> >
> 
> What is wrong to print "prerelease" with "gcc -v" on GCC 5 branch? If
> it isn't a prerelease, what is it? And let's call it what it is.

It's not a pre-release - it's a post-release.  We had confused
customers about this (and patched out that "prerelease" wording
while at the same time decreasing the patchlevel number, thus
instead of 4.8.4 (prerelease) [... revision 123] we shipped with 4.8.3
[... revision 123]).

prerelease just sounds wrong.

Richard.

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)

Re: My patch for GCC 5 directory names

[H.J. Lu]

On Tue, May 12, 2015 at 6:54 AM, Richard Biener <rguenther@suse.de> wrote:
> On Tue, 12 May 2015, H.J. Lu wrote:
>
>> On Tue, May 12, 2015 at 6:42 AM, Richard Biener <rguenther@suse.de> wrote:
>> >
>> > I promised to send out my pat^Whack.  Before building I introduce
>> > gcc/FULL-VER as copy of gcc/BASE-VER and adjust gcc/BASE-VER to
>> > just the major number.  Then I only need the following small
>> > patch (where I don't speak enough tcl for fixing libjava.exp "properly").
>> >
>> > Without the FULL-VER trick the patch would be much larger (BASE-VER
>> > is referenced a lot).  For a "real" patch (including configury) we
>> > probably want to generate a BASE-VER in the toplevel (or have
>> > a @BASE-VER@ substitute).
>> >
>>
>> What is wrong to print "prerelease" with "gcc -v" on GCC 5 branch? If
>> it isn't a prerelease, what is it? And let's call it what it is.
>
> It's not a pre-release - it's a post-release.  We had confused
> customers about this (and patched out that "prerelease" wording
> while at the same time decreasing the patchlevel number, thus
> instead of 4.8.4 (prerelease) [... revision 123] we shipped with 4.8.3
> [... revision 123]).
>
> prerelease just sounds wrong.
>

So we have

experimental
release
post-release

Why not just rename prerelease to post-release? That is a one-line
change.

-- 
H.J.

Re: My patch for GCC 5 directory names

[Richard Biener]

On Tue, 12 May 2015, H.J. Lu wrote:

> On Tue, May 12, 2015 at 6:54 AM, Richard Biener <rguenther@suse.de> wrote:
> > On Tue, 12 May 2015, H.J. Lu wrote:
> >
> >> On Tue, May 12, 2015 at 6:42 AM, Richard Biener <rguenther@suse.de> wrote:
> >> >
> >> > I promised to send out my pat^Whack.  Before building I introduce
> >> > gcc/FULL-VER as copy of gcc/BASE-VER and adjust gcc/BASE-VER to
> >> > just the major number.  Then I only need the following small
> >> > patch (where I don't speak enough tcl for fixing libjava.exp "properly").
> >> >
> >> > Without the FULL-VER trick the patch would be much larger (BASE-VER
> >> > is referenced a lot).  For a "real" patch (including configury) we
> >> > probably want to generate a BASE-VER in the toplevel (or have
> >> > a @BASE-VER@ substitute).
> >> >
> >>
> >> What is wrong to print "prerelease" with "gcc -v" on GCC 5 branch? If
> >> it isn't a prerelease, what is it? And let's call it what it is.
> >
> > It's not a pre-release - it's a post-release.  We had confused
> > customers about this (and patched out that "prerelease" wording
> > while at the same time decreasing the patchlevel number, thus
> > instead of 4.8.4 (prerelease) [... revision 123] we shipped with 4.8.3
> > [... revision 123]).
> >
> > prerelease just sounds wrong.
> >
> 
> So we have
> 
> experimental
> release
> post-release
> 
> Why not just rename prerelease to post-release? That is a one-line
> change.

Why print anything at all?  5.1.1 is after 5.1.0 in obvious ways.

Richard.

-- 
Richard Biener <rguenther@suse.de>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg)

Re: My patch for GCC 5 directory names

[H.J. Lu]

On Tue, May 12, 2015 at 7:01 AM, Richard Biener <rguenther@suse.de> wrote:
> On Tue, 12 May 2015, H.J. Lu wrote:
>
>> On Tue, May 12, 2015 at 6:54 AM, Richard Biener <rguenther@suse.de> wrote:
>> > On Tue, 12 May 2015, H.J. Lu wrote:
>> >
>> >> On Tue, May 12, 2015 at 6:42 AM, Richard Biener <rguenther@suse.de> wrote:
>> >> >
>> >> > I promised to send out my pat^Whack.  Before building I introduce
>> >> > gcc/FULL-VER as copy of gcc/BASE-VER and adjust gcc/BASE-VER to
>> >> > just the major number.  Then I only need the following small
>> >> > patch (where I don't speak enough tcl for fixing libjava.exp "properly").
>> >> >
>> >> > Without the FULL-VER trick the patch would be much larger (BASE-VER
>> >> > is referenced a lot).  For a "real" patch (including configury) we
>> >> > probably want to generate a BASE-VER in the toplevel (or have
>> >> > a @BASE-VER@ substitute).
>> >> >
>> >>
>> >> What is wrong to print "prerelease" with "gcc -v" on GCC 5 branch? If
>> >> it isn't a prerelease, what is it? And let's call it what it is.
>> >
>> > It's not a pre-release - it's a post-release.  We had confused
>> > customers about this (and patched out that "prerelease" wording
>> > while at the same time decreasing the patchlevel number, thus
>> > instead of 4.8.4 (prerelease) [... revision 123] we shipped with 4.8.3
>> > [... revision 123]).
>> >
>> > prerelease just sounds wrong.
>> >
>>
>> So we have
>>
>> experimental
>> release
>> post-release
>>
>> Why not just rename prerelease to post-release? That is a one-line
>> change.
>
> Why print anything at all?  5.1.1 is after 5.1.0 in obvious ways.
>

How can you tell GCC 5.1.1 on May 1, 2015 from GCC 5.1.1
on May 12, 2015?


-- 
H.J.

Re: My patch for GCC 5 directory names

[Michael Matz]

Hi,

On Tue, 12 May 2015, H.J. Lu wrote:

> >> So we have
> >>
> >> experimental
> >> release
> >> post-release
> >>
> >> Why not just rename prerelease to post-release? That is a one-line
> >> change.
> >
> > Why print anything at all?  5.1.1 is after 5.1.0 in obvious ways.
> >
> 
> How can you tell GCC 5.1.1 on May 1, 2015 from GCC 5.1.1
> on May 12, 2015?

Via the svn revision.  But as the subject says, this patch is not so much 
about the --version output (though it changes it in IMO sensible way), but 
rather about file and directory names, so that they are based only on the 
major version, not on the micro version (where major before gcc5 was X.Y, 
and now is only X).


Ciao,
Michael.

Re: My patch for GCC 5 directory names

[H.J. Lu]

On Tue, May 12, 2015 at 8:28 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 12 May 2015, H.J. Lu wrote:
>
>> >> So we have
>> >>
>> >> experimental
>> >> release
>> >> post-release
>> >>
>> >> Why not just rename prerelease to post-release? That is a one-line
>> >> change.
>> >
>> > Why print anything at all?  5.1.1 is after 5.1.0 in obvious ways.
>> >
>>
>> How can you tell GCC 5.1.1 on May 1, 2015 from GCC 5.1.1
>> on May 12, 2015?
>
> Via the svn revision.  But as the subject says, this patch is not so much

So? Doesn't post-release display the svn revision.for gcc -v, which
gcc -v doesn't display today? Something like this

diff --git a/gcc/DEV-PHASE b/gcc/DEV-PHASE
index e69de29..ee176f8 100644
--- a/gcc/DEV-PHASE
+++ b/gcc/DEV-PHASE
@@ -0,0 +1 @@
+post-release


> about the --version output (though it changes it in IMO sensible way), but
> rather about file and directory names, so that they are based only on the
> major version, not on the micro version (where major before gcc5 was X.Y,
> and now is only X).
>
>
> Ciao,
> Michael.



-- 
H.J.

Re: My patch for GCC 5 directory names

[Richard Biener]

On May 12, 2015 5:58:07 PM GMT+02:00, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>On Tue, May 12, 2015 at 8:28 AM, Michael Matz <matz@suse.de> wrote:
>> Hi,
>>
>> On Tue, 12 May 2015, H.J. Lu wrote:
>>
>>> >> So we have
>>> >>
>>> >> experimental
>>> >> release
>>> >> post-release
>>> >>
>>> >> Why not just rename prerelease to post-release? That is a
>one-line
>>> >> change.
>>> >
>>> > Why print anything at all?  5.1.1 is after 5.1.0 in obvious ways.
>>> >
>>>
>>> How can you tell GCC 5.1.1 on May 1, 2015 from GCC 5.1.1
>>> on May 12, 2015?
>>
>> Via the svn revision.  But as the subject says, this patch is not so
>much
>
>So? Doesn't post-release display the svn revision.for gcc -v, which
>gcc -v doesn't display today? Something like this
>
>diff --git a/gcc/DEV-PHASE b/gcc/DEV-PHASE
>index e69de29..ee176f8 100644
>--- a/gcc/DEV-PHASE
>+++ b/gcc/DEV-PHASE
>@@ -0,0 +1 @@
>+post-release

Printing post-release doesn't add any information.  I believe Jakub fixed the missing svn revision printing already.

Richard.

>
>> about the --version output (though it changes it in IMO sensible
>way), but
>> rather about file and directory names, so that they are based only on
>the
>> major version, not on the micro version (where major before gcc5 was
>X.Y,
>> and now is only X).
>>
>>
>> Ciao,
>> Michael.

Re: My patch for GCC 5 directory names

[H.J. Lu]

On Tue, May 12, 2015 at 9:09 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On May 12, 2015 5:58:07 PM GMT+02:00, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>On Tue, May 12, 2015 at 8:28 AM, Michael Matz <matz@suse.de> wrote:
>>> Hi,
>>>
>>> On Tue, 12 May 2015, H.J. Lu wrote:
>>>
>>>> >> So we have
>>>> >>
>>>> >> experimental
>>>> >> release
>>>> >> post-release
>>>> >>
>>>> >> Why not just rename prerelease to post-release? That is a
>>one-line
>>>> >> change.
>>>> >
>>>> > Why print anything at all?  5.1.1 is after 5.1.0 in obvious ways.
>>>> >
>>>>
>>>> How can you tell GCC 5.1.1 on May 1, 2015 from GCC 5.1.1
>>>> on May 12, 2015?
>>>
>>> Via the svn revision.  But as the subject says, this patch is not so
>>much
>>
>>So? Doesn't post-release display the svn revision.for gcc -v, which
>>gcc -v doesn't display today? Something like this
>>
>>diff --git a/gcc/DEV-PHASE b/gcc/DEV-PHASE
>>index e69de29..ee176f8 100644
>>--- a/gcc/DEV-PHASE
>>+++ b/gcc/DEV-PHASE
>>@@ -0,0 +1 @@
>>+post-release
>
> Printing post-release doesn't add any information.  I believe Jakub fixed the missing svn revision printing already.
>

What is the real benefit of your patch?


-- 
H.J.

Re: My patch for GCC 5 directory names

[Richard Biener]

On May 12, 2015 6:11:45 PM GMT+02:00, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>On Tue, May 12, 2015 at 9:09 AM, Richard Biener
><richard.guenther@gmail.com> wrote:
>> On May 12, 2015 5:58:07 PM GMT+02:00, "H.J. Lu" <hjl.tools@gmail.com>
>wrote:
>>>On Tue, May 12, 2015 at 8:28 AM, Michael Matz <matz@suse.de> wrote:
>>>> Hi,
>>>>
>>>> On Tue, 12 May 2015, H.J. Lu wrote:
>>>>
>>>>> >> So we have
>>>>> >>
>>>>> >> experimental
>>>>> >> release
>>>>> >> post-release
>>>>> >>
>>>>> >> Why not just rename prerelease to post-release? That is a
>>>one-line
>>>>> >> change.
>>>>> >
>>>>> > Why print anything at all?  5.1.1 is after 5.1.0 in obvious
>ways.
>>>>> >
>>>>>
>>>>> How can you tell GCC 5.1.1 on May 1, 2015 from GCC 5.1.1
>>>>> on May 12, 2015?
>>>>
>>>> Via the svn revision.  But as the subject says, this patch is not
>so
>>>much
>>>
>>>So? Doesn't post-release display the svn revision.for gcc -v, which
>>>gcc -v doesn't display today? Something like this
>>>
>>>diff --git a/gcc/DEV-PHASE b/gcc/DEV-PHASE
>>>index e69de29..ee176f8 100644
>>>--- a/gcc/DEV-PHASE
>>>+++ b/gcc/DEV-PHASE
>>>@@ -0,0 +1 @@
>>>+post-release
>>
>> Printing post-release doesn't add any information.  I believe Jakub
>fixed the missing svn revision printing already.
>>
>
>What is the real benefit of your patch?

It keeps an unchanging directory structure for the whole GCC 5 series (also requested by customers in the past). I've been asked to post the patch I am using for this.  Previous discussion concluded that we want a configury to control this.

Richard.

Re: My patch for GCC 5 directory names

[H.J. Lu]

On Tue, May 12, 2015 at 9:32 AM, Richard Biener <rguenther@suse.de> wrote:
> On May 12, 2015 6:11:45 PM GMT+02:00, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>On Tue, May 12, 2015 at 9:09 AM, Richard Biener
>><richard.guenther@gmail.com> wrote:
>>> On May 12, 2015 5:58:07 PM GMT+02:00, "H.J. Lu" <hjl.tools@gmail.com>
>>wrote:
>>>>On Tue, May 12, 2015 at 8:28 AM, Michael Matz <matz@suse.de> wrote:
>>>>> Hi,
>>>>>
>>>>> On Tue, 12 May 2015, H.J. Lu wrote:
>>>>>
>>>>>> >> So we have
>>>>>> >>
>>>>>> >> experimental
>>>>>> >> release
>>>>>> >> post-release
>>>>>> >>
>>>>>> >> Why not just rename prerelease to post-release? That is a
>>>>one-line
>>>>>> >> change.
>>>>>> >
>>>>>> > Why print anything at all?  5.1.1 is after 5.1.0 in obvious
>>ways.
>>>>>> >
>>>>>>
>>>>>> How can you tell GCC 5.1.1 on May 1, 2015 from GCC 5.1.1
>>>>>> on May 12, 2015?
>>>>>
>>>>> Via the svn revision.  But as the subject says, this patch is not
>>so
>>>>much
>>>>
>>>>So? Doesn't post-release display the svn revision.for gcc -v, which
>>>>gcc -v doesn't display today? Something like this
>>>>
>>>>diff --git a/gcc/DEV-PHASE b/gcc/DEV-PHASE
>>>>index e69de29..ee176f8 100644
>>>>--- a/gcc/DEV-PHASE
>>>>+++ b/gcc/DEV-PHASE
>>>>@@ -0,0 +1 @@
>>>>+post-release
>>>
>>> Printing post-release doesn't add any information.  I believe Jakub
>>fixed the missing svn revision printing already.
>>>
>>
>>What is the real benefit of your patch?
>
> It keeps an unchanging directory structure for the whole GCC 5 series (also requested by customers in the past). I've been asked to post the patch I am using for this.  Previous discussion concluded that we want a configury to control this.

Why do we have to change directory structure on GCC 5 branch?
Is there a GCC bug for this request?

-- 
H.J.

Re: My patch for GCC 5 directory names

[Richard Biener]

On Tue, 12 May 2015, H.J. Lu wrote:

> On Tue, May 12, 2015 at 9:32 AM, Richard Biener <rguenther@suse.de> wrote:
> > On May 12, 2015 6:11:45 PM GMT+02:00, "H.J. Lu" <hjl.tools@gmail.com> wrote:
> >>On Tue, May 12, 2015 at 9:09 AM, Richard Biener
> >><richard.guenther@gmail.com> wrote:
> >>> On May 12, 2015 5:58:07 PM GMT+02:00, "H.J. Lu" <hjl.tools@gmail.com>
> >>wrote:
> >>>>On Tue, May 12, 2015 at 8:28 AM, Michael Matz <matz@suse.de> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On Tue, 12 May 2015, H.J. Lu wrote:
> >>>>>
> >>>>>> >> So we have
> >>>>>> >>
> >>>>>> >> experimental
> >>>>>> >> release
> >>>>>> >> post-release
> >>>>>> >>
> >>>>>> >> Why not just rename prerelease to post-release? That is a
> >>>>one-line
> >>>>>> >> change.
> >>>>>> >
> >>>>>> > Why print anything at all?  5.1.1 is after 5.1.0 in obvious
> >>ways.
> >>>>>> >
> >>>>>>
> >>>>>> How can you tell GCC 5.1.1 on May 1, 2015 from GCC 5.1.1
> >>>>>> on May 12, 2015?
> >>>>>
> >>>>> Via the svn revision.  But as the subject says, this patch is not
> >>so
> >>>>much
> >>>>
> >>>>So? Doesn't post-release display the svn revision.for gcc -v, which
> >>>>gcc -v doesn't display today? Something like this
> >>>>
> >>>>diff --git a/gcc/DEV-PHASE b/gcc/DEV-PHASE
> >>>>index e69de29..ee176f8 100644
> >>>>--- a/gcc/DEV-PHASE
> >>>>+++ b/gcc/DEV-PHASE
> >>>>@@ -0,0 +1 @@
> >>>>+post-release
> >>>
> >>> Printing post-release doesn't add any information.  I believe Jakub
> >>fixed the missing svn revision printing already.
> >>>
> >>
> >>What is the real benefit of your patch?
> >
> > It keeps an unchanging directory structure for the whole GCC 5 series (also requested by customers in the past). I've been asked to post the patch I am using for this.  Previous discussion concluded that we want a configury to control this.
> 
> Why do we have to change directory structure on GCC 5 branch?
> Is there a GCC bug for this request?

We don't have to do this and we definitely are not going to change the 
default.

Richard.

Re: My patch for GCC 5 directory names

[Matthias Klose]

On 05/12/2015 03:42 PM, Richard Biener wrote:
> 
> I promised to send out my pat^Whack.  Before building I introduce
> gcc/FULL-VER as copy of gcc/BASE-VER and adjust gcc/BASE-VER to
> just the major number.  Then I only need the following small
> patch (where I don't speak enough tcl for fixing libjava.exp "properly").
> 

for reference, I'm using something similar for the distro packaging,
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-5/debian/patches/gcc-base-version.diff?view=markup

addressing additional things like

 - c++ incdir
 - differentiating between the full version and the base version
   (you probably want to print out the full version for -v)

> Without the FULL-VER trick the patch would be much larger (BASE-VER
> is referenced a lot).  For a "real" patch (including configury) we
> probably want to generate a BASE-VER in the toplevel (or have
> a @BASE-VER@ substitute).

that would be nice, but then maybe introduce another macro GCCSUBDIR for
gcc/<alias>/<version>.

Matthias