[x265] x265: Questions and comments from an outsider

[Steve Borho]

On Thu, Sep 12, 2013 at 6:22 AM, Derek Buitenhuis <
derek.buitenhuis at gmail.com> wrote:

> On 9/12/2013 12:03 PM, Derek Buitenhuis wrote:
> > I am sure I am missing some things, so any community members should add
> any I forgot.
>
> Indeed I forgot one.
>
>
> Build System
> ------------
>
> People hate cmake. A lot. This is pretty much the biggest complaint I hear
> from people who poke x265. Cross compiling is a crapshoot. To get even
> base features like 'make install' or 'make uninstall' or proper library
> handling, you need to write mountains of custom stuff.
>
> I understand the main point is for MSVC support, so my proposal is to do
> what LLVM does and have both an autotools system, and a cmake system.
> For all the perceived hate autotools gets, autoconf, automake, and libtool
> are by far the Least Bad build system in terms of handling everything
> properly (library generation, versioning, cross-comiling, etc.). If I
> or some other developer were to write this (it wont be a lot of code),
> could I count on it actually being updated at the same time as the cmake
> system?
>

I hadn't heard that much discontent about cmake, so this is good feedback.

cmake does have support for install rules, I just haven't made any yet (we
didn't have a real deployable static library until yesterday).

http://www.cmake.org/Wiki/CMake_FAQ#Installation_questions

I'll summarize my long term thoughts:

Today our CMake scripts support cc+make, 3 msvc releases, msys, icl+nmake,
and Xcode.
autoconf is essentially cc+make

Clearly cmake has more breadth and there is overlap between the two, but I
also understand that the vast bulk of open source is autoconf based and so
if adding autoconf is a precondition for integration into other transcode
tools then I'll definitely take a patch which introduces autoconf support
and maintain it to the best of my abilities.

It will be a constant source of friction, having two build systems, but
other projects manage to deal with it.

--
Steve

-- 
Steve Borho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20130912/92614ffb/attachment.html>