[petsc-dev] those who use cmake are SANE

[Matthew Knepley]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131111/b7b1bdcb/attachment.html>