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" <[email protected]> > À: "Franck Houssen" <[email protected]> > Cc: "petsc-dev" <[email protected]> > 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 < [email protected] > > wrote: > > ----- Mail original ----- > > > > De: "Satish Balay" < [email protected] > > > > > À: "Franck Houssen" < [email protected] > > > > > Cc: "petsc-dev" < [email protected] > > > > > 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/
