<div dir="ltr">On Mon, Nov 11, 2013 at 2:34 PM, "C. Bergström" <span dir="ltr"><<a href="mailto:cbergstrom@pathscale.com" target="_blank">cbergstrom@pathscale.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><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">On 11/12/13 03:20 AM, Matthew Knepley 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">
On Mon, Nov 11, 2013 at 1:21 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a> <mailto:<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>>> wrote:<br>
<br>
<br>
Man o man, it is worse than autoconf (how is that possible?)<br>
<br>
<br>
Its the essential masochism of programming, where shitty interfaces are elevated to<br>
grand status because some people can cope with them. Notice that this phenomenon<br>
also appears in mathematics.<br>
</blockquote>
Just a drive-by comment, but I can't help add to some flames to this<br>
Are you people on drugs?<br>
<br>
1) My personal hands on experience - I'd rather deal with cmake syntax than m4 any day of the week<br>
2) cmake is super easy to bootstrap everywhere - autocrap and all the auto* stuff is a bitch by comparison<br>
3) cmake is more or less portable and adding new backends is possible (ninja)<br>
4) cmake projects typically lack the idiot proof ./configure --help option list, but there is ccmake (which I've never used). (Internally we overcome this with good documentation)<br>
-------------<br>
I know of some complaints about the cmake codebase itself - I'm not going to comment on those.<br>
<br>
cmake may leave a rash, but better than having gangrene aka autoconf<br>
--------------<br>
More productively - Specific complaints about cmake? Have any of those complaints been raised on the cmake developers list? In my experience they are quite responsive<br></blockquote></div><div class="gmail_extra"><br></div>
I guess I cannot resist. I am starting a list of CMake badness. Here is the first draft (and Jed kicks it off):</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">We have used CMake, but are not greatly impressed by it. Some issues:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">* Configuration in batch environments: CMake requires "platform files";</div><div class="gmail_extra"> we submit conftest so we work automatically in more places</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">* Dependencies: CMake wants to convert all dependent packages to CMake</div><div class="gmail_extra"> in order to build them, typically as a "submodule"; we download</div>
<div class="gmail_extra"> optionally and use that project's native build system.</div><div class="gmail_extra"><br></div><div class="gmail_extra">* CMake does not produce good diagnostics for debugging configuration</div>
<div class="gmail_extra"> systems by email and CMake itself crashes in some contexts, but</div><div class="gmail_extra"> upstream has not been very responsive (I can point to mailing list</div><div class="gmail_extra"> threads); we write everything needed to configure.log and use it to</div>
<div class="gmail_extra"> debug thousands of broken environments per year (user error is the</div><div class="gmail_extra"> most common: incompatible libraries/compiler/etc)</div><div class="gmail_extra"><br></div><div class="gmail_extra">
* A CMake configuration mixes together lots of auto-discovered things</div><div class="gmail_extra"> with those explicitly passed by the user. Compiler and</div><div class="gmail_extra"> dependent-library upgrades can change what should be in</div>
<div class="gmail_extra"> CMakeCache.txt, but it's hard to update or create configurations that</div><div class="gmail_extra"> are similar to an existing configuration without storing the arguments</div><div class="gmail_extra">
out-of-band.</div><div class="gmail_extra"><br></div><div class="gmail_extra">* CMake's scripting language is atrocious for writing logic of any sort.</div><div class="gmail_extra"> Note that Trilinos/TriBITS contains 175k lines of cmakescript. All</div>
<div class="gmail_extra"> Python code in PETSc, including BuildSystem and various other scripts</div><div class="gmail_extra"> amounts to 30k lines, plus one GNU Makefile of 130 lines.</div><div class="gmail_extra"><br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Regarding workflow, the PETSc team advocates an open development process</div><div class="gmail_extra">that makes it easier for external people to get involved. For example,</div>
<div class="gmail_extra">my first three years of PETSc development was entirely outside and there</div><div class="gmail_extra">are about 30 outside people that have contributed code to PETSc in the</div><div class="gmail_extra">
last year. This openness also helps us collaborate on new features with</div><div class="gmail_extra">downstream applications, some of which we were not aware of when</div><div class="gmail_extra">starting the new feature. There is a significant price to be paid for</div>
<div class="gmail_extra">keeping all development secret, and we don't see "scooping" as an</div><div class="gmail_extra">especially great threat. Such anti-social behavior is also a lot easier</div><div class="gmail_extra">
to call out when the commit history is public.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The Git mechanics we use are different from MPAS and the git-flow model</div><div class="gmail_extra">that their approach is approximately based on (though MPAS rebases more</div>
<div class="gmail_extra">than git-flow recommends; rebasing is bad for downstream and invalidates</div><div class="gmail_extra">prior testing, which often leads to people chasing the same bugs</div><div class="gmail_extra">
multiple times in different contexts). Anyway, after PETSc adopted our</div><div class="gmail_extra">current workflow (similar to gitworkflows(7)), I wrote the following</div><div class="gmail_extra">critique of git-flow for the FEniCS project, which has now adopted</div>
<div class="gmail_extra">PETSc's approach (along with the EPSI project (Center for Edge Physics</div><div class="gmail_extra">Simulation) and others).</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="http://mail-archive.com/search?l=mid&q=87zjx4x417.fsf@mcs.anl.gov">http://mail-archive.com/search?l=mid&q=87zjx4x417.fsf@mcs.anl.gov</a></div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Comparison to BuildSystem:</div><div class="gmail_extra"><br></div><div class="gmail_extra">- CMake runs simple autoconf tests</div>
<div class="gmail_extra"> - check_function_exists() just checks the symbol</div><div class="gmail_extra"> - will not do the right thing in C++ because you need a declaration</div><div class="gmail_extra"> - will also fail for Windows name mangling</div>
<div class="gmail_extra"> - try_compile() needs entire list of libraries in LIBS</div><div class="gmail_extra"> - no easy way to get libs from other tests in modular fashion</div><div class="gmail_extra"> - Sticks results in flat namespace of env vars</div>
<div class="gmail_extra">- No configure or build subpackages</div><div class="gmail_extra"> - This would reduce complexity</div><div class="gmail_extra"> - Find*.cmake are poorly maintained and almost every one is broken for static libraries</div>
<div class="gmail_extra">- Cross-compilation support is very weak in the sense that it requires a human expert to write a platform file</div><div class="gmail_extra">- If you have a dependent library that needs -lstdc++, but you are writing a C project, you have to jump through insane hoops</div>
<div class="gmail_extra">- Compiler-private libraries are a mess because CMake wants to resolve full paths </div><div class="gmail_extra">- Caching is broken</div><div class="gmail_extra"> - CMake's not tracking dependencies between variables makes it very difficult to write a Find*.cmake that properly resets itself if you change a variable that it depends on </div>
<div class="gmail_extra"><br></div><div class="gmail_extra">BuildSystem:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) Namespacing:</div><div class="gmail_extra"><br></div><div class="gmail_extra">BS tests are wrapped up in modules, which also hold the test results. Thus you get the normal Python namespacing of</div>
<div class="gmail_extra">results. As simple as this sounds, SCons does not do it, nor CMake, nor Autoconf. They all use one flat namespace. Also,</div><div class="gmail_extra">when we build up command lines, you can see where options came from, whereas in the others, all flags are dumped into</div>
<div class="gmail_extra">reservoirs like INCLUDE and LIBS.</div><div class="gmail_extra"><br></div><div class="gmail_extra">2) Explicit control flow</div><div class="gmail_extra"><br></div><div class="gmail_extra">These modules (one object comes from each module) are organized explicitly in a DAG. The user indicates dependence with</div>
<div class="gmail_extra">a single call, requires('path.to.other.test'), which not only structures the DAG, but returns the object so that this</div><div class="gmail_extra">test can use the results of the test it depends on. I think this is the most elegant thing in BS.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">3) Multi-languages tests</div><div class="gmail_extra"><br></div><div class="gmail_extra">We have explicit pushing and popping of languages, so builds can use any one they want, all with their own compilers,</div>
<div class="gmail_extra">flags, libraries, etc. Thus its easy for us to do cross-language checks in a few lines, whereas this is very hard in all</div><div class="gmail_extra">the others. PETSc does a lot of this.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">4) Subpackages</div><div class="gmail_extra"><br></div><div class="gmail_extra">This is the most complicated and probably most useful part of BS. We have a object scaffolding for including your</div>
<div class="gmail_extra">package (several people have used this) so that PETSc downloads, builds, and tests it for inclusion. Its not that</div><div class="gmail_extra">elegants (lots of switches), but its really useful. For some packages, people use them through PETSc because it will get</div>
<div class="gmail_extra">it and build it automatically. The other systems have no idea of hierarchy (autoconfs subconfigures are laughable).</div><div><br></div><div> Matt</div><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>