<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I've been quiet on this list, but I do want to emphasize a point that Matt is making: The build system has a very, very hard job. Thus it must either be designed so that it creates actionable diagnostics if it fails or it must have unfailingly good, 24x7 support. Neither autoconf nor cmake have either, but autoconf, for all of its ickyness, lets a skilled user gain access to enough information (possibly by adding set -x) to act. I have given up on cmake projects in the past because I could not get useful diagnostics and could not get the project built.<div><br></div><div>Other things that Matt mentions, particularly the ability to work with foreign packages, are also vital. But working in all environments, or at least being fixable, is an absolute requirement.<br><div><br></div><div>Bill</div><div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="font-size: 12px; ">William Gropp</div><div style="font-size: 12px; ">Director, Parallel Computing Institute</div><div style="font-size: 12px; ">Deputy Director for Research</div><div style="font-size: 12px; ">Institute for Advanced Computing Applications and Technologies</div></div></div></span><span class="Apple-style-span" style="font-size: 12px; ">Thomas M. Siebel Chair in Computer Science</span><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="font-size: 12px; ">University of Illinois Urbana-Champaign</div></div><div><br></div></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br><div><div>On Nov 11, 2013, at 3:09 PM, Matthew Knepley wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><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>
</blockquote></div><br></div></div></body></html>