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

[Pavel Emelyanov]

On 01/21/2015 08: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,
>> ...
>> Guys, lets vote? Pavel, Andrew, Ruslan?
> 
> I vote for _not_ using automake and friends too, ...
> 
> Lets see what Pavel and Andey think about it.

I don't have any experience with auto-tools, so I can't make a qualified
decision. The internet is full of both -- use and don't use -- advises
and AFAIU make-vs-automake is another standard holly-war out there.

But CRIU coding style, development model, build system and quite a lot of
other things are copied from the Linux kernel. And most of the kernel 
people ... do not quite like auto-tools for some reason.

Thus, from this perspective (but only from this), I'd prefer leaving the
existing build system, unless we have strong technical evidence of the 
need to switch to new stuff.

Thanks,
Pavel