[libvirt] [PATCH] examples: Use one top level makefile

Cole Robinson crobinso at redhat.com
Sun Jan 10 19:22:57 UTC 2016


On 01/10/2016 05:37 AM, Martin Kletzander wrote:
> On Sat, Jan 09, 2016 at 09:20:44PM -0500, Cole Robinson wrote:
>> Using one Makefile per example subdirectory essentially serializes 'make'
>> calls. Convert to one example/Makefile that builds and distributes
>> all the subdir files. This reduces example/ rebuild time from about 5.8
>> seconds to 1.5 seconds on my machine.
>>
>> One slight difference is that we no longer ship Makefile.am with the
>> examples in the rpm. This was virtually useless anyways since the Makefile
>> was very specific to libvirt infrastructure, so wasn't generically
>> reusable anyways.
>>
>> Tested with 'make distcheck' and 'make rpm'
> 
> Looks good to me, ACK.
> 

Thanks, pushed.

> I've never realized that such separation spoils the parallel build.  But
> of course it does, since there is onely one process needed for each of
> those example directories.  I also thought it has the added benefit of
> Makefile per example soit can be shown, but that has no usage at all.
> 
> So this is nice, I would just want to know if we could also speed up the
> compilation by passing some hints to $(MAKE) so that it knows that using
> more than one process for that subdirectory would be wasting.
> 


Looks like there's a way to manually do it:

https://stackoverflow.com/questions/1681006/parallelization-of-recursive-jobs-in-gnu-make
https://www.gnu.org/software/make/manual/html_node/Double_002dColon.html

But the issue is you need to ensure that none of the subdirs have an
interdependency. In the examples/ case it would be fine, but it's not future
proof. The benefit of the non-recursive/non-subdirs usage is that the top
level Makefile knows all the dependencies of the subdirs, so it can figure out
the dependency graph for us and optimally parallelize. And also it saves the
pain of adding new Makefile.am for each new example, having to touch
configure.ac, etc.

Thanks,
Cole




More information about the libvir-list mailing list