Jed might have better suggestion [wrt cmake code and petsc] You might have to explain why you can't use FindPETSc.cmake - and need PETScConfig.cmake.
Satish On Tue, 13 Oct 2015, Arne Morten Kvarving wrote: > Right. Then I will keep patching as there is no other easy way to use petsc > in a portable way. Too many defines used in too many headers for me to do > bother writing my own find rule. > > Thanks for your answers. > > > -------- Opprinnelig melding -------- > Fra: Satish Balay <[email protected]> > Dato: 13.10.2015 17.53 (GMT+01:00) > Til: Arne Morten Kvarving <[email protected]> > Ko: petsc-users <[email protected]> > Emne: Re: [petsc-users] petsc cmake config - BUILD_SHARED_LIBS > > As mentioned - PETScConfig.cmake is primarily for building PETSc - and > not equivalent to .pc file > > It gets used when 'make all-cmake' is used instead of the default > 'make all' to build petsc libraries. > > [This mode is deprecated - and not properly tested - and I see its currenty > broken] > > Jed had a tool FindPETSc.cmake - which is a tool for the user to > detect petsc config via cmake. > > https://github.com/jedbrown/cmake-modules/ > > Is this what you are using? > > Satish > > On Tue, 13 Oct 2015, Arne Morten Kvarving wrote: > > > Yes I am aware and i can reset and such. > > This is about the why, not the how. The config file has nothing to do with > > the petsc build system, it is for users of petsc, like a .pc file > > (pkgconfig). > > > > The code in question builds a number of convenience libraries for shared > > code between multiple apps. I want these static at times but in general > > shared for installs. This I control using the intended cmake mechanism - > > namely the BUILD_SHARED_LIBS variable. Petsc breaks this since it overrides > > the value passed by the user. > > > > I would rather avoid hacking my buildsystem to workaround petsc bugs. Right > > now i need to deploy a patched petsc everywhere for this reason - to remove > > the useless variable writing in the cmake config file. Because as you say > > shared libs should normally be used. > > > > > > -------- Opprinnelig melding -------- > > Fra: Satish Balay <[email protected]> > > Dato: 13.10.2015 16.56 (GMT+01:00) > > Til: Arne Morten Kvarving <[email protected]> > > Ko: [email protected] > > Emne: Re: [petsc-users] petsc cmake config - BUILD_SHARED_LIBS > > > > Well the current code has the option of building petsc via cmake [but > > this mode is deprecated - and the default build uses straight gnumake] > > > > So if you configure PETSc with --shared-libraries=1 [default] - this > > flag is set in conf/PETScConfig.cmake > > > > So you can rebuild petc with --shared-libraries=0 - and this flag will > > go away. > > > > BTW: I'm not sure why this affects your application. [as applications > > don't build libraries]. Or is it that you have a library that builds > > over PETSc? > > > > [in this case - it generally makes sense to build it as shared anyway] > > > > Also - I'm guessing - there must be a way for you to reset this variable in > > your cmake config - if thats whats requred by your app. > > > > Jed should be able to confirm.. > > > > Satish > > > > > > On Tue, 13 Oct 2015, Arne Morten Kvarving wrote: > > > > > hi there; > > > > > > why does the cmake config file set the BUILD_SHARED_LIBS variable? this > > > affects all buildsystem where the config file is included, and has 0 > > > effect on > > > the actual petsc side of things. > > > > > > i don't see why petsc should decided whether i want to use static > > > libraries in > > > my application or not. > > > i can keep hacking around it, or supply a patch to get rid of it. but i > > > figured i'd ask for the reasoning first. > > > > > > if this should have gone to -dev, i'm sorry. i thought it fit better here. > > > > > > arnem > > > > > > > > > > > >
