> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
