| Message ID | 20110502195345.B0A371DA1C4@topo.tor.corp.google.com |
|---|---|
| State | New |
| Headers | show |
On Mon, May 2, 2011 at 2:53 PM, Diego Novillo <dnovillo@google.com> wrote: > > Since google/gcc-4_6 follows the 4.6 branch, changes in minor > revisions cause unnecessary churn in directory names. > > Fixed with this. OK for google/gcc-4_6? Yes, okay for google/gcc-4_6. Thanks, Ollie
On 05/02/2011 09:53 PM, Diego Novillo wrote: > Since google/gcc-4_6 follows the 4.6 branch, changes in minor > revisions cause unnecessary churn in directory names. > > Fixed with this. OK for google/gcc-4_6? > > Google ref 4335466. > > * BASE-VER: Change to 4.6.x-google. > > diff --git a/gcc/BASE-VER b/gcc/BASE-VER > index 4110f74..33d4edd 100644 > --- a/gcc/BASE-VER > +++ b/gcc/BASE-VER > @@ -1 +1 @@ > -4.6.1-google > +4.6.x-google is this enough? the subminor version number is encoded in more places, e.g. C++ headers, Go libraries, jar files. For the Debian/Ubuntu packaging I'm just using symlinks from 4.6.x to 4.6 to avoid this kind of dependency. Now that the -V option isn't supported anymore, maybe this could be addressed with something like a new configure option --version-alias=<value>, similar to the target alias. Matthias
On Wed, May 4, 2011 at 12:20 AM, Matthias Klose <doko@ubuntu.com> wrote: > On 05/02/2011 09:53 PM, Diego Novillo wrote: >> >> Since google/gcc-4_6 follows the 4.6 branch, changes in minor >> revisions cause unnecessary churn in directory names. >> >> Fixed with this. OK for google/gcc-4_6? >> >> Google ref 4335466. >> >> * BASE-VER: Change to 4.6.x-google. >> >> diff --git a/gcc/BASE-VER b/gcc/BASE-VER >> index 4110f74..33d4edd 100644 >> --- a/gcc/BASE-VER >> +++ b/gcc/BASE-VER >> @@ -1 +1 @@ >> -4.6.1-google >> +4.6.x-google > > is this enough? the subminor version number is encoded in more places, e.g. > C++ headers, Go libraries, jar files. For the Debian/Ubuntu packaging I'm > just using symlinks from 4.6.x to 4.6 to avoid this kind of dependency. Now > that the -V option isn't supported anymore, maybe this could be addressed > with something like a new configure option --version-alias=<value>, similar > to the target alias. The SUSE packages introduce gcc/FULL-VER as copy of BASE-VER and strip the patch-level version from BASE-VER. Some (but not many) makefiles need to be adjusted to use FULL-VER but then everything else just falls out nicely (and you lose the ability to install 4.6.0 and 4.6.1 in parallel, of course). For some weird marketing reasons we also drop "prerelease" from the version string and drop the patch-level version down to the last release. Richard. > Matthias >
On Tue, May 3, 2011 at 18:20, Matthias Klose <doko@ubuntu.com> wrote: > On 05/02/2011 09:53 PM, Diego Novillo wrote: >> >> Since google/gcc-4_6 follows the 4.6 branch, changes in minor >> revisions cause unnecessary churn in directory names. >> >> Fixed with this. OK for google/gcc-4_6? >> >> Google ref 4335466. >> >> * BASE-VER: Change to 4.6.x-google. >> >> diff --git a/gcc/BASE-VER b/gcc/BASE-VER >> index 4110f74..33d4edd 100644 >> --- a/gcc/BASE-VER >> +++ b/gcc/BASE-VER >> @@ -1 +1 @@ >> -4.6.1-google >> +4.6.x-google > > is this enough? the subminor version number is encoded in more places, e.g. > C++ headers, Go libraries, jar files. It work here so far. All the places where the version number is encoded in ultimately get it from BASE-VER. For us, the important thing is to avoid the churn in installed directory names and such. What the version string says is not as important. Diego
diff --git a/gcc/BASE-VER b/gcc/BASE-VER index 4110f74..33d4edd 100644 --- a/gcc/BASE-VER +++ b/gcc/BASE-VER @@ -1 +1 @@ -4.6.1-google +4.6.x-google