[petsc-dev] those who use cmake are SANE

[Barry Smith]

On 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

   I do not nor would advocate using autoconf (though I like its command line API (which we use with PETSc)). The reason that I bitched is that I would expect a “replacement” to autoconf to be orders of magnitude better than autoconf and to have a much much better way of helping end USERS when something goes wrong.  When some package's cmake craps out (and yes they do) I would hope for very useful diagnostics of what failed and possible ways to fix it. Instead you seem to get rather generic error messages which don’t tell what else to try.  I dislike the model “well when cmake craps out contact the package maintainer and they may respond, or not, to help you”. I want the diagnostics to get me over most hurdles on installing.


> --------------
> More productively - Specific complaints about cmake? Have any of those complaints been raised on the cmake developers list?

   Yup and they’ve been ignored.

> In my experience they are quite responsive

  If it doesn’t involve work on their part.

>