gcc-4.5-RH in F14

[Roland McGrath]

> So I'd package up stuff, do a koji build, download it, run my
> representative test suite, upload the result and do another build.

Oh.  Well, sure then.  What was the question?  You don't want much of it
automated at all then, but you're asking about the little?  

The profiled build will litter your world with .gcda files, and we'll have
to select some useful convention for -fprofile-dir= in builds and then
setting GCOV_PREFIX/GCOV_PREFIX_STRIP environment variables when you do
your run so you know where it will put them.

I can see doing some rpm macro magic to tweak RPM_OPT_FLAGS for the build
and implicitly generate a subpackage of the .gcno files.  Those are the
compile-time half of what you need to feed back into the final build.

Then you'd need to get that subpackage (or its contents, the .gcno files)
along with your collected .gcda files into something that could be a
SourceN: for the final build.  I'm really not sure how to tie that into the
whole rpmbuild/mock/koji world.  To preserve the actual bit for bit
reproducibility of builds that makes koji great, that tarball (or whatever
it is, all the .gcno and .gcda files) needs to be saved forever along with
the build.  We can do it with automation over the current process, where it
goes into the lookaside cache and its signature committed in the sources
file and all that.  Or it could be some sort of special koji magic where
the koji rpmbuilds just slurp from some koji database via some permanent
identifier URL or whatnot, e.g. a URL set in an rpm macro that koji sets on
an rpmbuild for "koji build --profileball=foo.tar.xz ..." after storing it
there for posterity.


Thanks,
Roland