[gccsdk] quilt management of patches
John.Tytgat at aaug.net
Sat Jul 14 10:15:11 PDT 2007
In message <865950024f.peter at chocky.org>
Peter Naulls <peter at chocky.org> wrote:
> In message <3381f5014f.Jo at hobbes.bass-software.com>
> John Tytgat <John.Tytgat at aaug.net> wrote:
> > In message <4e6b00004f.peter at chocky.org>
> > Peter Naulls <peter at chocky.org> wrote:
> > I must be missing something. It is just running create-gccsdk + build-it
> > and then you have your installed cross-compiler.
> Yes, you are. Have you read the README lately? Seriously - there are
> a considerable number of manual things you need to do.
I start thinking I made the README file too explicit and probably too
foolproof which overwelmed you. Step 1 is not really necessary but included
because the steps for getting the original sources is using environment
variables mentioned in setup-gccsdk-params. Apart from that it is not
needed as create-gccsdk and build-it will fetch setup-gccsdk-params
The steps 2 and 3 is about getting gcc and binutils sources and they only
have to be done once. This can be wrapped in a simple script which could
simply use setup-gccsdk-params so that step 1 is not needed.
Step 4 and 5 is actual building which is not a simple 'make' but
'create-gccsdk && build-it' which I don't think is overcomplicated compared
to a 'make'. The second part of step 5 is saying how you can restart a
build after it failed or after you made fixes. Oh, and that happens by
'make' (or do 'make install' which will install as well if the build
succeeded). It also mentions how you can pass CFLAGS for tuning the
target build, this is just FYI.
And if you look at build-it, it is just a conveniant wrapper for the
classic configure (with the right set of parameters) and make (install)
As I said before, the projects in riscos/* are not hooked in (point 2.2).
Maybe one of these days it will (after I get the riscos build working I
What else do we have : a topic explaining on how testing could be done.
Totally optional if you want to do this (but of course encouraged).
Another one on combining GCCSDK 3.4.6 in the same tree as GCCSDK 4, that's
something I will remove as it is no longer relevant IMHO. Oh and as last
bit a Credits section.
So apart from wrapping steps 2 and 3 in a script (eliminating step 1 as
well), are we still having "considerable number of manual things" then ?
If so what else do you suggest as improvement ?
> You are making
> the mistake of being so familiar with it so you don't see the issues.
Aren't we having a discussion on priorities here ? I would be very
surprised if the current build instructions are preventing (new) developers
spending sparetime on the project. I think for those people the instructions
are clear enough right now. Instead of trying lower the barrier more without
immediate benefit of getting more developers (or wasting time for the
existing developers ones), I'm focusing on getting issues sorted out to get
GCCSDK release ready. If we're somewhere at the end of that, I'm sure we
spend time on getting it more smoothly built as we then can test it within
Autobuilder which will probably give us plenty of feedback on issues and
what the release status is.
> > Let's try to be more precise please. Which Wiki documentation ?
> > <URL:http://www.riscos.info/index.php/GCCSDK_Development> ? If so, feel
> > free to improve it. I started this page so that it is more public where
> > we (Lee & I) are at the moment. It is ment for GCCSDK Developers,
> > not for the casual cross-compiler builder and user as we haven't addressed
> > those people for GCCSDK 4 yet.
> I'm both a "casual cross-compliler build" and a Developer. I don't
> think it is a matter of individual fixes to the documentation - it's the
> other way around. The system itself needs to be simple, and clear
> documentation will follow. I stand by my assertion that is is presently
What I'm trying to say is that we haven't made documentation for the
"casual cross-compiler builder", or at least that was not my intension.
What we have right now is intended for the developer (both README and the
above mentioned Wikie page) to get up to speed and yes there might be bumps
in the road which can be improved but if a developer can't survive
that, then I would suggest that gcc/binutils is not the place for that
person to go as that's far more bumpy and challenging then the steps in the
> > > up + make. Remember, it has to be usable by people who only build it a
> > > couple of times too, not those using it constantly. There's a world of
> > > difference.
> > For *those* people I don't see a relevant difference between
> > "svn update && make" and "svn update && ./create-gccsdk && ./build-it"
> > creating & installing the cross compiler.
> Well, for starters you missed the "svn up" in the second comparision.
Euh ? Really ?
> You missed the variables that need to be set,
Oh those two export ones.
Feel free to suggest a patch for improving on the need of having to
explicitly set up the LTCONFIG_VERSION environment variable. Simply moving
it to setup-params-gccsdk won't do it as we will have people complain that
if they do a simple make in the build tree the LTCONFIG_VERSION variable is
not known and will break the build. Maybe you can fix the real issue so
that this is not needed.
The 2nd and last variable is GCCSDK_NOE1F which is needed because it
breaks one of the configure steps after a change in the linker you made
to have ,e1f as executable extension. My suggestion for improvement
is to reverse this behaviour, ie. have GCCSDK_E1F which enables the
,e1f executable extension while default we don't.
I really hope we're not having a discussion on having those two variables
in wrapping makefile/script ?
> and you missed having to
> rebuild the entire thing if the change is just minor (improvements to
> Unixlib as many are).
I haven't missed that. You've missed my answer on that point in my message
<409bf1014f.Jo at hobbes.bass-software.com> ("Also with multilib configuration
I can't get..." etc).
If that problem isn't fixed then people will be disappointed that partial
rebuild after a UnixLib update doesn't end with the same result as a full
rebuild. Feel free to have a look at this problem and if it can be
solved we can indeed go for blind partial rebuilds for such changes.
But my claim is that we're better off advising developers to do a full
rebuild after importing changes from svn. This always works (assuming the
commiter did his work properly by doing a full rebuild test himself). Yes,
you can take shortcuts doing a partial rebuild for some changes (sometimes
requiring extra fiddling work) but no, it is nearly impossible to say when
that's going to work. Heck, even the gcc developers themselves require to
do a full bootstrap and even a test queue run before they submit or
checking patches. Why do you think the bootstrap would be needed ?
> John - you don't need to defend the current system.
I don't *feel* defending it right now but if it comes over like that then
it's because so far I haven't seen worthwhile project gains in the discussion
so far. But note that I've said that we're not yet there to address the
occational cross-compiler users. Or at least I'm not there yet. I've a
feeling your comments are more applicable for that end-phaze of the project.
If you feel taking a headstart on that, do some concrete proposals, let's
find an agreement and start currying then.
> I think the
> complexities are self-evident. Let's focus on what we can do.
I gave a suggestion in <409bf1014f.Jo at hobbes.bass-software.com> but
it is far from bullet proof and not really worth the hassle IMHO. I
didn't see much enthousiasm from Lee either so I don't think we should
The 2nd suggestion mentioned above is to make a small script wrapping up
step 2 and 3 from the README which also eliminates step 1. But note that
this only needs to be done once because as soon as you have right
gcc/binutils you can keep on reusing it until we decide to go to newer
version(s). That's a 10 minute job but probably won't pay off until we
have a new developer coming on board which will save him, say, 5 minutes.
My 3rd suggestion is to change the GCCSDK_NOE1F into GCCSDK_E1F (or
some equivalent name) and reversing its implementation (ie you only get
",e1f" when setting that environment variable). Then GCCSDK_E1F is setup
in Autobuilder only.
If you have any proposal for build infrastructure changes (like how to
use quilt for the patch management), feel free to send a patch to me or
the mailing list or make a branch in svn repository showing it so we can
try it out and evaluate and please, pretty please, don't change the
current one in gccsdk/gcc4 without some agreement from us. After more than
9 months of gcc/binutils hacking I started to know a couple of things which
could avoid some developer frustration afterwards. I'm sure Lee also has
experience which is useful to have consulted first.
John Tytgat, in his comfy chair at home BASS
John.Tytgat at aaug.net ARM powered, RISC OS driven
More information about the gcc