Re: building binutils from same directory as gcc (was: Re: xgcc does not find gcc-4.6.0-go/./binutils/ar (because it is gcc-4.6.0-go/./binutils/binutils/ar))

Re: building binutils from same directory as gcc (was: Re: xgcc does not find gcc-4.6.0-go/./binutils/ar (because it is gcc-4.6.0-go/./binutils/binutils/ar))

[Steffen Dettmer]

[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]

On Sat, Apr 30, 2011 at 12:38 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> I tried to express this in this form:
>> --- gcc-4.6.0.dist/gcc/doc/install.texi 2011-03-21 13:13:26.000000000 +0100
>> +++ gcc-4.6.0/gcc/doc/install.texi      2011-04-28 15:59:53.000000000 +0200
>> +via SVN, it is reliable. Unpacking into the same directory means
>> +that the contents of the (versionized) directories of binutils
>
> versionized?

Thank you, "versioned" seems to be the word I was looking for.

>> What should I do now, mail to gcc-patches?
>
> Yes, patches should always be sent there for discussion and review.

ok, so I Cc:.



* http://gcc.gnu.org/contribute.html:
> Legal Prerequisites

None ("Small changes can be accepted without a copyright
disclaimer or a copyright assignment on file")

> A description of the problem/bug and how your patch addresses it.

Users of release tarballs could get confused how to build
binutils and gcc and accidently attempt an undesired "combined
build". The patch adds some explaining words.

> Testcases

None. I don't know whether to add a doc test and how to do so.

> ChangeLog

2011-05-02 Steffen Dettmer <steffen@dett.de>

	* doc/install.texi (Downloading the Source): Recommended
	not to build binutils in combined mode when using release
	tarballs.

(to be replaced this by a correct one if an improvement based on
the proposal in form of my patch is considered for a commit)

> Bootstrapping and testing

This change was not tested at all.

> The patch itself

--- gcc-4.6.0.dist/gcc/doc/install.texi 2011-03-21 13:13:26.000000000 +0100
+++ gcc-4.6.0/gcc/doc/install.texi      2011-05-02 14:39:01.000000000 +0200
@@ -553,7 +553,17 @@
 If you also intend to build binutils (either to upgrade an existing
 installation or for use in place of the corresponding tools of your
 OS), unpack the binutils distribution either in the same directory or
-a separate one.  In the latter case, add symbolic links to any
+a separate one. Using the same directory is not recommended for
+building release tarballs of gcc, but if you obtained the sources
+via SVN, it is reliable. Unpacking into the same directory means
+that the contents of the (versioned) directories of binutils
+and gcc are in one and the same directory (with subdirectories
+like @file{gcc}, @file{binutils} and @file{gas}). Contents of the
+directories common to and shared by gcc and binutils
+(@file{include}, @file{libiberty} and @file{intl}) must be
+compatible, making combined builds using standard releases hard
+to get right.  In case you are using separate directories, which
+is recommended, add symbolic links to any
 components of the binutils you intend to build alongside the compiler
 (@file{bfd}, @file{binutils}, @file{gas}, @file{gprof}, @file{ld},
 @file{opcodes}, @dots{}) to the directory containing the GCC sources.

[-- Attachment #2: gcc-4_6_0_gcc_doc_install.texi.diff --]
[-- Type: application/octet-stream, Size: 1330 bytes --]

--- gcc-4.6.0.dist/gcc/doc/install.texi	2011-03-21 13:13:26.000000000 +0100
+++ gcc-4.6.0/gcc/doc/install.texi	2011-05-02 14:39:01.000000000 +0200
@@ -553,7 +553,17 @@
 If you also intend to build binutils (either to upgrade an existing
 installation or for use in place of the corresponding tools of your
 OS), unpack the binutils distribution either in the same directory or
-a separate one.  In the latter case, add symbolic links to any
+a separate one. Using the same directory is not recommended for
+building release tarballs of gcc, but if you obtained the sources
+via SVN, it is reliable. Unpacking into the same directory means
+that the contents of the (versioned) directories of binutils
+and gcc are in one and the same directory (with subdirectories
+like @file{gcc}, @file{binutils} and @file{gas}). Contents of the
+directories common to and shared by gcc and binutils
+(@file{include}, @file{libiberty} and @file{intl}) must be
+compatible, making combined builds using standard releases hard
+to get right.  In case you are using separate directories, which
+is recommended, add symbolic links to any
 components of the binutils you intend to build alongside the compiler
 (@file{bfd}, @file{binutils}, @file{gas}, @file{gprof}, @file{ld},
 @file{opcodes}, @dots{}) to the directory containing the GCC sources.

Re: building binutils from same directory as gcc

[Gerald Pfeifer]

I see this was not applied, and also did not get any review comments.

Let me add our build system maintainers. 

If something like this goes in, I suggest to avoid direct references
to SVN (which is a technical detail) and use something more generic
and spell GCC as opposed to gcc when it refers to the overall project.

My other note is that this is too complicated.  Why not just declare
that building from the same directory is not support and have one
simple set of instructions that always works, as opposed to "this
ought to work with snapshots but not with direct checkouts"?

Thoughts?

(If Steffen provides an updated patch based on this and/or your
feedback, I'll be happy to apply it if approved.)

Gerald

On Mon, 2 May 2011, Steffen Dettmer wrote:
>> A description of the problem/bug and how your patch addresses it.
> 
> Users of release tarballs could get confused how to build
> binutils and gcc and accidently attempt an undesired "combined
> build". The patch adds some explaining words.
> 
> 2011-05-02 Steffen Dettmer <steffen@dett.de>
> 
> 	* doc/install.texi (Downloading the Source): Recommended
> 	not to build binutils in combined mode when using release
> 	tarballs.
> 
> --- gcc-4.6.0.dist/gcc/doc/install.texi 2011-03-21 13:13:26.000000000 +0100
> +++ gcc-4.6.0/gcc/doc/install.texi      2011-05-02 14:39:01.000000000 +0200
> @@ -553,7 +553,17 @@
>  If you also intend to build binutils (either to upgrade an existing
>  installation or for use in place of the corresponding tools of your
>  OS), unpack the binutils distribution either in the same directory or
> -a separate one.  In the latter case, add symbolic links to any
> +a separate one. Using the same directory is not recommended for
> +building release tarballs of gcc, but if you obtained the sources
> +via SVN, it is reliable. Unpacking into the same directory means
> +that the contents of the (versioned) directories of binutils
> +and gcc are in one and the same directory (with subdirectories
> +like @file{gcc}, @file{binutils} and @file{gas}). Contents of the
> +directories common to and shared by gcc and binutils
> +(@file{include}, @file{libiberty} and @file{intl}) must be
> +compatible, making combined builds using standard releases hard
> +to get right.  In case you are using separate directories, which
> +is recommended, add symbolic links to any
>  components of the binutils you intend to build alongside the compiler
>  (@file{bfd}, @file{binutils}, @file{gas}, @file{gprof}, @file{ld},
>  @file{opcodes}, @dots{}) to the directory containing the GCC sources.
> 

Re: building binutils from same directory as gcc

[Andrew Haley]

On 10/30/2011 01:51 PM, Gerald Pfeifer wrote:
> Why not just declare
> that building from the same directory is not support and have one
> simple set of instructions that always works, as opposed to "this
> ought to work with snapshots but not with direct checkouts"?

That's right.  Is there ever any advantage to building in-srcdir?
I'm not aware of one.

Andrew.

Re: building binutils from same directory as gcc

[Mike Stump]

On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote:
> On 10/30/2011 01:51 PM, Gerald Pfeifer wrote:
>> Why not just declare
>> that building from the same directory is not support and have one
>> simple set of instructions that always works, as opposed to "this
>> ought to work with snapshots but not with direct checkouts"?
> 
> That's right.  Is there ever any advantage to building in-srcdir?

Yes.  You can do configure && make && make install.

Re: building binutils from same directory as gcc

[Andrew Haley]

On 11/01/2011 04:51 PM, Mike Stump wrote:
> On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote:
>> On 10/30/2011 01:51 PM, Gerald Pfeifer wrote:
>>> Why not just declare
>>> that building from the same directory is not support and have one
>>> simple set of instructions that always works, as opposed to "this
>>> ought to work with snapshots but not with direct checkouts"?
>>
>> That's right.  Is there ever any advantage to building in-srcdir?
> 
> Yes.  You can do configure && make && make install.

Huh?  I do that all the time without building in-srcdir. I need a path
to "configure", but that'll always be true for everyone who doesn't
have "." in their PATH.

Andrew.

Re: building binutils from same directory as gcc

[Mike Stump]

On Nov 2, 2011, at 2:42 AM, Andrew Haley wrote:
> On 11/01/2011 04:51 PM, Mike Stump wrote:
>> On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote:
>>> On 10/30/2011 01:51 PM, Gerald Pfeifer wrote:
>>>> Why not just declare
>>>> that building from the same directory is not support and have one
>>>> simple set of instructions that always works, as opposed to "this
>>>> ought to work with snapshots but not with direct checkouts"?
>>> 
>>> That's right.  Is there ever any advantage to building in-srcdir?
>> 
>> Yes.  You can do configure && make && make install.
> 
> Huh?

Ah, yes, yet another advantage, one can also do:

  ./configure && make && make install

:-)  I do realize that you may not choose to value the feature, but that doesn't mean that everyone has the same valuation you have.

Re: building binutils from same directory as gcc

[Andrew Haley]

On 11/02/2011 05:11 PM, Mike Stump wrote:
> On Nov 2, 2011, at 2:42 AM, Andrew Haley wrote:
>> On 11/01/2011 04:51 PM, Mike Stump wrote:
>>> On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote:
>>>> On 10/30/2011 01:51 PM, Gerald Pfeifer wrote:
>>>>> Why not just declare
>>>>> that building from the same directory is not support and have one
>>>>> simple set of instructions that always works, as opposed to "this
>>>>> ought to work with snapshots but not with direct checkouts"?
>>>>
>>>> That's right.  Is there ever any advantage to building in-srcdir?
>>>
>>> Yes.  You can do configure && make && make install.
>>
>> Huh?
> 
> Ah, yes, yet another advantage, one can also do:
> 
>   ./configure && make && make install

Of course.  That's what "building in-srcdir" means.

> :-) I do realize that you may not choose to value the feature, but
> that doesn't mean that everyone has the same valuation you have.

Sure, but that doesn't answer the question, which was "is there ever
any advantage to building in-srcdir?"  The answer "Yes: one can build
in srcdir" doesn't quite do it!

Andrew.

Re: building binutils from same directory as gcc

[Mike Stump]

On Nov 2, 2011, at 10:17 AM, Andrew Haley wrote:
> Sure, but that doesn't answer the question, which was "is there ever
> any advantage to building in-srcdir?"  The answer "Yes: one can build
> in srcdir" doesn't quite do it!

Well, unstated in that is that one doesn't have to manually create an object directory.  Also, unstated in that, is that to build a random package, one doesn't have to read the documentation to configure and build it, they can just build it. and it will just work.  These are the advantages.

It used to be the case, a long time ago, that building software was a random hodge-podge of weird random commands, the situation has been improving over the years to standardize on a few small incantations that work.  The configure && make && make install, was the command standardized on, right after make && make install.

It is like explaining the advantage of a red stop light being red.  It is red, because all stop lights are red.  This is nicely circular.  The reason _why_ is have a standard, isn't just to make the light red, it is so that all users of all stop lights expect it to be red, and if it weren't bad things would happen.

We make ./configure && make && make install work, because our users expect it to work, and there is no reason to break that assumption.