David Brown schrieb:
On 04/03/2011 06:20, Trevor Woerner wrote:
On Thu, Mar 3, 2011 at 11:38 PM, Omar
Choudary<choudary.o...@gmail.com> wrote:
Trevor, your idea seems nice, although I would be even more
enthusiastic to put all the patches into the mainstream gcc and
then just do a normal cross-build for the tools.
Yes, ideally this would be the best solution.
However, given the fact the patches exist but are still not yet
merged into the gcc project I simply assumed getting these patches
accepted by the gcc maintainers is not trivial.
One could use the GCC build machinery, anyway. Or is that too
restricted? Up to now I have just experience with canadian crosses with
--build=linux --host=mingw32 and --target=foo and that works out of the
box. (After you got/built cross-build tools from linux to mingw32). For
linux guys this is easier than doing native build under cygwin or
whatever with build=host (actually I never tried that because the
canonical solution works fine).
It always takes time (and effort!) for patches to make their way into
the main FSF gcc tree, and it takes time before these patches end up
in released versions. gcc has a fair amount of bureaucracy, and the
tree supports a vast number of ports, hosts, and combinations.
You have to go through the bureaucracy only once (signing FSF/GPL
stuff). As far as I can tell, getting patches into avr backend is no big
deal, at least for straight forward stuff (I did'n yet try to get more
elaborate stuff into avr). Even though GCC supports fair amount of
whatever, avr development takes place in a small (with respect to rest
of GCC) sandbox: the avr backend. Other parts of GCC are not affected by
the work in that sandbox and thus is no issue for maintainers other than
avr backend maintainers.
Johann
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
