On 06/15/2016 11:22 AM, Daniel P. Berrange wrote:
On Wed, Jun 15, 2016 at 10:31:16AM -0400, Laine Stump wrote:
This allows us to produce releases that are roughly a third in size, have no limitation on path length, and are still readable by all supported platforms. --- I just want to point out that the tarfile is built every time you run "make rpm" (which I do quite a lot - I prefer installing rpms to the carnage created by make install), and this increases the time for make rpm on my system by 1min38sec. (jtomko may have something to say about that, since he's been interested in shaving fractions of a second off the build time in
On 06/15/2016 09:03 AM, Andrea Bolognani wrote: the last few days :-O)
Am I going to need to carry a local patch to revert this so that I don't get *even more* bored waiting for builds to complete? Or is there a reasonable way to make it easily configurable with a switch to autogen? (even then I would still need a patch to the specfile, unless we could make it happen based on some environment setting). You really shouldn't waste your time doing make rpm all the time IMHO.
./autogen.sh --system make -j 12 sudo systemctl stop libvirtd.service sudo ./daemon/libvirtd
will "just work(tm)" - its how I've done all libvirt development for years.
Yeah, I used to do it that way, and at some point I switched to just making the rpm and installing it. I don't even remember now why I did that - it could have just been because I was testing on a different machine from where I was building, or maybe I was rebooting a lot and wanted my new libvirtd to be the one that came up at boot time. At the time I switched, the penalty was small enough that it just became automatic, but over the last year or so the build time (for make -j$LOTS rpm) has slowly crept up to the point where it's now time to retrain my muscle memory and use the in-tree libvirtd. I suppose one downside of that is that make rpm failures won't be noticed as quickly :-)