[petsc-dev] those who use cmake are SANE

[Barry Smith]

On Nov 11, 2013, at 3:57 PM, William Gropp <wgropp at illinois.edu> wrote:

> 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.

    Bill,

     Thanks, you hit the nail on the head. That was actually my grip when I sent out my email though I articulated it very badly; getting all possible diagnostics somewhat reasonably organized is crucial.

    Barry

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