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

[Franck Houssen]

Don't want to fight on this !...

In "real everyday daily life", in 99% of the cases :
- nobody never finds .pc files (because nobody wants to set PKG_CONFIG_PATH, or even know it exists, or want to know about it ! So nobody never finds the .pc file)
- find_package is a lot more reliable than any Find*.cmake: say "find hammer and it comes to you" is more reliable than "searching the outer hyper space up to Asgard across the Bifrost (and what if Heimdall has been frozen by Locki ?)" 

In "real life", find_package can use hints and can piggy-back into PATH (pc files don't): that's what makes it reliable.

Anyway... I have no religion, I am not gonna fight. All this is weird to me: you did a very good job all the way long (managers don't say that enough ! the configure you provide IS helpful in many cases), you climbed the "Mont Blanc" up to the top... And jam everything 15 minutes from the summit. Can't understand that ! :D (joking)

----- Mail original -----
> De: "Garth N. Wells" <gnw20 at cam.ac.uk>
> À: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: "Matthew Knepley" <knepley at gmail.com>, "petsc-dev" <petsc-dev at mcs.anl.gov>
> Envoyé: Mardi 7 Novembre 2017 10:28:31
> Objet: Re: [petsc-dev] CMake: make, install, find_package ?
> 
> 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/
> >
> >
>