| Message ID | BANLkTimoi-WbtLSCGCLXAOwSn-A1DOaRdg@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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. >
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.
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.
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.
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.
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.
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.
--- 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.