This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: translating in-source builds, next round (was Re: gcc/gcc ChangeLog doc/install.texi)
> Is there a technical reason for rejection, out of curiosity? Does it
> render some other part of the build mechanism unstable or break backwards
> compatability? I am much confused.
It fixes a problem that does not exist, and moves the build out of the
"usual" location. IMHO when someone does "./configure" they expect an
in-source build, which facilitates debugging and development (for
them). This change gratuitously makes it impossible to have objects
and sources in the same directory, punishing those who prefer that
type of environment.
Of all the packages I've downloaded and built over the years, this is
the first time I've seen one that didn't build objects in the source
directories with "./configure". Since none of *us* develop that way,
there's no reason for us to argue that the change makes it easier to
work with the build. Since an in-source build works, there's no
reason to approve the patch as a bug fix. Without a compelling reason
*for* the patch, confusion for the end user and deviation from normal
(net-wide) expectations is a compelling reason *against* it.