<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 13, 2013 at 4:21 AM, Derek Buitenhuis <span dir="ltr"><<a href="mailto:derek.buitenhuis@gmail.com" target="_blank">derek.buitenhuis@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">> 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).<br>

<br>
</div>Don't forget uninstall! ;)<br></blockquote><div><br></div><div>There were instructions in the cmake FAQ for making uninstall rules, but they are, ahem less than optimal.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im"><br>
> Today our CMake scripts support cc+make, 3 msvc releases, msys, icl+nmake, and Xcode.<br>
<br>
</div>I wanted to ask about soething related to this:<br>
<br>
What's with the build/* directories? These seem rather silly<br>
to me, when proper builds should be done out-of-tree, i.e.:<br>
<br>
$ hg clone <...><br>
$ mkdir x265_build<br>
$ cd x265_build<br>
$ cmake -G "something" ../x265<br>
$ make</blockquote><div><br></div><div>It's just convenience for Windows developers.  If you have VC9, VC10, and/or VC11 installed, you can just click on the applicable batch file, select the build options you want from the GUI, then double-click on the generated solution file and build it.</div>
<div><br></div><div>Without the various directories of batch files, you would have to scour your start menu for the appropriate compiler's terminal shell launcher, and then run cmake from within that environment; or explicitly tell CMake the name of the MSVC generator you want to use; and the naming convention for those has changed between VC9 and VC11.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> 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.<br>

<br>
</div>I think it's a question or portability and usability. There's e.g.<br>
no analogue for 'configure --help' in cmake. Also large concern<br>
with cmake, for me anyway, is that it's a very very big pain to<br>
make it handle cross-compiling correctly... I've formed this<br>
opinion after having worked on the Yocto Project / Poky Linux /<br>
OpenEmbedded projects as my day job previously.<br>
<br>
Maybe this has changed?<br></blockquote><div><br></div><div>I'll concede the point on portability and cross-compiling.  Though JEEB did report his success with it:</div><div><br></div><div><a href="https://bitbucket.org/multicoreware/x265/wiki/CrossCompile">https://bitbucket.org/multicoreware/x265/wiki/CrossCompile</a><br>
</div><div> </div><div>the config --help analog in cmake is cmake-gui (Qt) or ccmake (ncurses)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> It will be a constant source of friction, having two build systems, but other projects manage to deal with it.<br>
<br>
</div>I will wait to see how cmake turns out before submitting a patch<br>
for autotools.</blockquote><div><br></div><div>Yeah, I suspect an autotools script will arrive the first time someone butts heads with CMake and decides it would be less work to just add an autoconf script.</div><div><br>
</div><div>--</div></div>Steve Borho
</div></div>