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
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
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,
Joseph == Joseph S Myers jos...@codesourcery.com 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
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 sed
(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 to the
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, cgen,
sid, and
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
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
Joseph S. Myers jos...@codesourcery.com 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
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 jos...@codesourcery.com 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
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 such
On Tue, 29 Mar 2011, Ian Lance Taylor wrote:
Joseph S. Myers jos...@codesourcery.com 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
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
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
16 matches
Mail list logo
