[petsc-users] petsc cmake config - BUILD_SHARED_LIBS

[Arne Morten Kvarving]

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 <balay at mcs.anl.gov>
Dato: 13.10.2015 16.56 (GMT+01:00)
Til: Arne Morten Kvarving <Arne.Morten.Kvarving at sintef.no>
Ko: petsc-users at mcs.anl.gov
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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20151013/de9c2490/attachment.html>