[petsc-dev] CMake: make, install, find_package ?

[Garth N. Wells]

On 7 November 2017 at 09:17, Franck Houssen <franck.houssen at inria.fr> wrote:
> Seems you really had a very bad experience with CMake. Not gonna fight. :D
> (joking)
> I'll stick to pkg-config: that's fine to me.
>

Here is an example FindPETSc.cmake file that extracts data from
petsc.pc via pkg-config:

    https://bitbucket.org/fenics-project/dolfin/src/3505ffd12c72dd40bec5b705ea364b453e242c1d/cmake/modules/?at=master&fileviewer=file-view-default

Garth

> Franck
>
> ________________________________
>
> De: "Matthew Knepley" <knepley at gmail.com>
> À: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: "petsc-dev" <petsc-dev at mcs.anl.gov>
> Envoyé: Lundi 6 Novembre 2017 19:28:57
> Objet: Re: [petsc-dev] CMake: make, install, find_package ?
>
> On Mon, Nov 6, 2017 at 12:49 PM, Franck Houssen <franck.houssen at inria.fr>
> wrote:
>>
>> ----- Mail original -----
>> > De: "Satish Balay" <balay at mcs.anl.gov>
>> > À: "Franck Houssen" <franck.houssen at inria.fr>
>> > Cc: "petsc-dev" <petsc-dev at mcs.anl.gov>
>> > Envoyé: Lundi 6 Novembre 2017 16:08:55
>> > Objet: Re: [petsc-dev] CMake: make, install, find_package ?
>> >
>> > On Mon, 6 Nov 2017, Franck Houssen wrote:
>> >
>> > >
>> > > Yes ! Your friend let you the keys of his car. The car has no wheel.
>> > > Why
>> > > did he gave you his keys ?!... :D (joking)
>> >
>> > Actually - its more akin to - friend gives you a car - and leaves the
>> > keys in the console, with instructions there.
>>
>> :D
>>
>> > However you look arround in the trunk and find something that looks like
>> > a key - and assume hay
>> > - it must start this car - and retool it and start the car with it :)
>> >
>> > Anyhow - Barry wants to get rid of the cmake related code from petsc..
>> >
>>
>> Yeah, that's your decision ! But know that, if you impose a full global
>> ordering of all packages of all possible dependencies (to be done once =
>> associating a unique number to each package), then:
>> 1. "your" configure (python) will probably also benefit of it (less "bugs"
>> when reconfiguring for instance, ...).
>> 2. cmake and find_package will work (with commits in the bundle I sent):
>> this could be nice to lots of people too...
>>
>> Dependencies order seems to have been the base line systematic problem you
>> had: neither cmake, nor autotools are meant to deal with the graph of
>> dependencies (no way they can do that), this must be guaranteed by the dev
>> (no choice).
>> Who was first ? Chicken or Egg ? How to know ? :D CMake/autotools can not
>> know if blas needs lapack or if it is the other way !
>>
>> Dependencies order must be imposed :
>
>
> You fix that, you fix everything (+ get cmake for free).
>
>> in configure, that's already what you do already (but only locally -
>> scalapack knows it needs mpi and lapack).
>> If you do that globally, you solve everything at once (in likely 15 to 30
>> mins !) and avoid cmake to deal with problems (order) he has no way to
>> solve.
>
>
> That is a terrible model. You have a closed world assumption, which is the
> opposite of what we want for configure. You would end up renumbering all the
> time.
>
>
> No. 1 release = 1 order. This is what is done in ALL softwares !
>
> Instead we use topological sort to impose a total order on the fly. This is
> why we have mathematics, to figure out the right thing to do without
> enumerating everything ahead of time.
>
>    Matt
>>
>> > Satish
>> >
>
>
>
>
> --
> 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
>
> https://www.cse.buffalo.edu/~knepley/
>
>