[CRIU] [PATCH] make: protobuf -- Rework build procedure

[Christopher Covington]

On 01/21/2015 12:10 PM, Ruslan Kuprieiev wrote:
> 
> On 01/21/2015 06:28 PM, Cyrill Gorcunov wrote:
>> On Wed, Jan 21, 2015 at 08:12:18AM -0800, Filipe Brandenburger wrote:
>>> Hi,
>>>
>>> On Wed, Jan 21, 2015 at 4:04 AM, Cyrill Gorcunov <gorcunov at gmail.com> wrote:
>>>> no problem, this makefile has to be cleaned up anyway.
>>> As long as recursive makefiles are being used, it's unlikely that all
>>> build problems will be fixed and that -j will reliably work... I have
>>> always had problems with -j in criu build (so I solved it by not using
>>> -j).
>>> May I suggest using non-recursive makefiles instead?
>>>
>>> I would volunteer to move criu towards a "./configure; make; make
>>> install" style of build using automake, autoconf and libtool, with a
>>> non-recursive Makefile.am. That would make parallel build with -j work
>>> reliably, make Makefile.config more reliable, get rid of
>>> scripts/Makefile.*, make out-of-tree builds work, etc. Would that be
>>> something that interests you? In other words, if I do the work, would
>>> you accept the contribution? Or do you have reasons to keep the
>>> current build system (even if sometimes it's a pain to maintain to
>>> support things like -j)?
>> Well, I personally would like to escape using automake and friends,
>> but on the other hands there might be more experts in automake
>> than plain make and this would bring more people to support
>> building procedure. So that I leave it to the rest of the dev
>> crew (while I personally prefer plain make, I can happily live
>> with any approach ;)
>>
>> Guys, lets vote? Pavel, Andrew, Ruslan?
> 
> I vote for _not_ using automake and friends too, as the current build system
> handles everything nicely(even though I've managed to break it, but that was
> mainly because of poor flexibility of protoc-c... I guess =) ) and I personally
>  don't think that replacing make with a zoo of tools is needed, unless you have
> something that really requires it to work.

Something that would be nice to have that the current build system does not
handle is out-of-tree building. When I say out-of-tree building, I mean all
configure, build, run, etc. artifacts are placed in a directory outside of the
source tree. The Linux kernel build system allows for example:

mkdir ../arm ../arm64 ../x86
make ARCH=arm O=../arm &
make ARCH=arm64 O=../arm64 &
make ARCH=x86 O=../x86

With CRIU I've had to rsync the source into each architecture or
configuration's build directory, but since this isn't a very big
inconvenience, I've not yet worked to change it.

Looking through my build recipes, it appears that in some cases (GDB, ncurses)
I've been able to build autotooled projects out of tree, but in others
(old-ish protobuf and protobuf-c) I've not been able to because I have to run
autoreconf or something like that in the source tree. So I think out-of-tree
building is possible with either plain make or autotools.

Autotools generated configure scripts seem to take a while, which can be
annoying, but again, not enough for me to really do something about like
figuring out how to set up a site pre-configuration.

Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project