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

[Ruslan Kuprieiev]

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.

A year ago I sent a patch that was using autotools to handle libbsd 
detection
for setproctitle(), but it turned out that current build system is able 
to handle
that in a quite easy way, so there really was no need to use autotools.
So, if you need autotools to solve some problem - tell us, there is a chance
that it could be solved with current build system.

I also saw a bunch of discussions about autotools and they all tend to claim
that autotools are quite bad =).

Lets see what Pavel and Andey think about it.