On Thu, 31 Mar 2011, Paolo Bonzini wrote:
> On 03/30/2011 05:54 PM, Joseph S. Myers wrote:
> > Thanks. My inclination is to say that this should be considered an
> > independent tool in its own repository, as something not required in the
> > build of any of the other tools. More specifically, u
On 03/30/2011 05:15 PM, Joseph S. Myers wrote:
On Tue, 29 Mar 2011, Joseph S. Myers wrote:
Specifically, I propose removal of all support for building: ash autoconf
automake bash byacc bzip2 diff dosutils fileutils findutils find gawk
gettext gnuserv gzip hello indent libiconv libtool make mmal
On 03/30/2011 05:54 PM, Joseph S. Myers wrote:
Thanks. My inclination is to say that this should be considered an
independent tool in its own repository, as something not required in the
build of any of the other tools. More specifically, utils/mep and
utils/wince look like independent tools ea
On Wed, 30 Mar 2011, DJ Delorie wrote:
> > > (h) utils - I don't know what to do with this directory or where it best
> > > goes.
> >
> > relates to the other bits of src and where it would best go if src is
> > split up.
>
> For example, the MeP utils is used to reconfigure gcc, binutils, cge
> > (h) utils - I don't know what to do with this directory or where it best
> > goes.
>
> relates to the other bits of src and where it would best go if src is
> split up.
For example, the MeP utils is used to reconfigure gcc, binutils, cgen,
sid, and a few other places (libgloss) according t
On Tue, 29 Mar 2011, Joseph S. Myers wrote:
> Specifically, I propose removal of all support for building: ash autoconf
> automake bash byacc bzip2 diff dosutils fileutils findutils find gawk
> gettext gnuserv gzip hello indent libiconv libtool make mmalloc patch perl
> prms rcs release recode
> "Joseph" == Joseph S Myers writes:
Joseph> Additional tools for the build (not host) system may be built
Joseph> (not installed) when present in the source tree, if of direct
Joseph> use in building and testing the components in those
Joseph> repositories, and likewise additional libraries
On Tue, 29 Mar 2011, Frank Ch. Eigler wrote:
> Perhaps if we do move to git for all the /src stuff, we can have a
It is very strongly in my principle 6 that there should be no "we" moving
"for all the /src stuff" - that it should be made possible for each
project (a) through (i) to make its own
> Perhaps if we do move to git for all the /src stuff, we can have a
> /toplevel git repository with different branches suitable for each
> of your tastes of such policy.
Perhaps I misunderstand how this would work (/me hates git) but I'm
not looking forward to adding support to umpteen million b
On Tue, 29 Mar 2011, Ian Lance Taylor wrote:
> "Joseph S. Myers" writes:
>
> > Specifically, I propose removal of all support for building: ash autoconf
> > automake bash byacc bzip2 diff dosutils fileutils findutils find gawk
> > gettext gnuserv gzip hello indent libiconv libtool make mmalloc
dj wrote:
>> [...]
> I see no reason to stop people from building in a combined source tree
> for multiple targets, and expecting it to work.
Perhaps if we do move to git for all the /src stuff, we can have a
/toplevel git repository with different branches suitable for each of
your tastes of su
"Joseph S. Myers" writes:
> Specifically, I propose removal of all support for building: ash autoconf
> automake bash byacc bzip2 diff dosutils fileutils findutils find gawk
> gettext gnuserv gzip hello indent libiconv libtool make mmalloc patch perl
> prms rcs release recode sed send-pr shell
On Tue, 29 Mar 2011, DJ Delorie wrote:
> > 2. If you put directories from the GCC repository into your build, you
> > should expect GCC and its libraries to be built; toplevel should not
> > disable GCC on the grounds that GCC does not support a given target.
>
> I disagree. We have a single
"Joseph S. Myers" writes:
> 2. If you put directories from the GCC repository into your build, you
> should expect GCC and its libraries to be built; toplevel should not
> disable GCC on the grounds that GCC does not support a given target.
I'd appreciate it if creating a combined tree and b
> 2. If you put directories from the GCC repository into your build, you
> should expect GCC and its libraries to be built; toplevel should not
> disable GCC on the grounds that GCC does not support a given target.
I disagree. We have a single combined gcc+binutils+etc internal tree
that's u
Having been cleaning up the toplevel configure.ac in various ways
following removing deprecated targets for GCC 4.7, I would like to propose
some principles relating to the toplevel configure and build system.
These are intended as principles to guide future development and indicate
the direct
16 matches
Mail list logo
