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

[Franck Houssen]

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. 

Franck 

----- Mail original -----

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