On Nov 11, 2013, at 3:57 PM, William Gropp <[email protected]> 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" <[email protected]>
>> wrote:
>> On 11/12/13 03:20 AM, Matthew Knepley wrote:
>> On Mon, Nov 11, 2013 at 1:21 PM, Barry Smith <[email protected]
>> <mailto:[email protected]>> 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&[email protected]
>>
>>
>> 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
>
