[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

[rwild at gcc dot gnu dot org]

--- Comment #8 from rwild at gcc dot gnu dot org  2010-02-25 20:53 ---
(In reply to comment #2)
> I think one way to start addressing this would be to transport an unexpanded
>   docdir='${datarootdir}/doc/${PACKAGE}'
> 
> through to the sub makes (it's fairly irrelevant whether datarootdir is
> expanded
> in the toplevel or not, ${PACKAGE} is important so that it can vary between 
> the
> different components of the tree.
> 
> Right now I don't see how to escape this thing properly so it gets through the
> toplevel machinery.
> 

Maybe Paolo has a good idea (or alternative) for this, let's CC him.


-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

[Ralf dot Wildenhues at gmx dot de]

--- Comment #7 from Ralf dot Wildenhues at gmx dot de  2010-02-24 18:19 
---
(In reply to comment #6)
> I think the key question here is whether it is possible to build/install a new
> version of GCC, getting the same directory layout as was the default in
> previous versions.  It's OK if it takes command-line options, but I think it
> should be *possible*.  If not, then I think it is a regression.

I'm fairly certain that it is possible to get the old layout back using
command-line options, but that, too, should be documented in changes.html (PR
43133).  I'll try it to make sure, though, and report back.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

[mmitchel at gcc dot gnu dot org]

--- Comment #6 from mmitchel at gcc dot gnu dot org  2010-02-24 16:28 
---
Ralf --

I think the key question here is whether it is possible to build/install a new
version of GCC, getting the same directory layout as was the default in
previous versions.  It's OK if it takes command-line options, but I think it
should be *possible*.  If not, then I think it is a regression.

Do you know the answer?

Thanks,

-- Mark


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

[Ralf dot Wildenhues at gmx dot de]

--- Comment #5 from Ralf dot Wildenhues at gmx dot de  2010-02-23 06:01 
---
Well, the GCS did change, and we did (mostly) update the default locations to
follow.  However, as of now, the override methods don't all work the way the
configure --help output promises, and not all documentation gets put in
directories containing a coherent expansion of ${PACKAGE}.

Anyway, not marking this as regression then.  Thanks.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

[mmitchel at gcc dot gnu dot org]

--- Comment #4 from mmitchel at gcc dot gnu dot org  2010-02-22 23:23 
---
I don't think this should be P1, as getting the old behavior is apparently
doable by hand, but I'm a big fan of backwards-compatibility and if the GCS
haven't been updated then I think that GCC (as a GNU package) ought to try to
follow that.

Thanks,

-- Mark


-- 

mmitchel at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

[Ralf dot Wildenhues at gmx dot de]

--- Comment #3 from Ralf dot Wildenhues at gmx dot de  2010-02-22 21:39 
---
Not sure if this can be qualified a regression, but still, making a
release manager aware of this can't hurt, I guess.


-- 

Ralf dot Wildenhues at gmx dot de changed:

   What|Removed |Added

 CC||mark at codesourcery dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

[rwild at gcc dot gnu dot org]

--- Comment #2 from rwild at gcc dot gnu dot org  2010-02-21 17:27 ---
I think one way to start addressing this would be to transport an unexpanded
  docdir='${datarootdir}/doc/${PACKAGE}'

through to the sub makes (it's fairly irrelevant whether datarootdir is
expanded
in the toplevel or not, ${PACKAGE} is important so that it can vary between the
different components of the tree.

Right now I don't see how to escape this thing properly so it gets through the
toplevel machinery.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

[rwild at gcc dot gnu dot org]

-- 

rwild at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-02-21 16:29:16
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

[rwild at gcc dot gnu dot org]

--- Comment #1 from rwild at gcc dot gnu dot org  2010-02-21 16:28 ---
*** Bug 43134 has been marked as a duplicate of this bug. ***


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132