[petsc-users] petsc cmake config - BUILD_SHARED_LIBS

[Arne Morten Kvarving]

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

[Satish Balay]

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
>
>

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

[Satish Balay]

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

[Arne Morten Kvarving]

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

[Satish Balay]

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

[Jed Brown]

Satish Balay <***@mcs.anl.gov> writes:

> As mentioned - PETScConfig.cmake is primarily for building PETSc - and
> not equivalent to .pc file

def dumpCMakeConfig(self):
'''
Writes configuration-specific values to ${PETSC_ARCH}/lib/petsc/conf/PETScConfig.cmake.
This file is private to PETSc and should not be included by third parties
(a suitable file can be produced later by CMake, but this is not it).
'''

Arne, is this the file you are talking about? It is part of the legacy
cmake build and is used to hold the various ARCH-specific variables when
building PETSc. (Note that this build does not use CMake for configure
since CMake is disgusting for that purpose and also because we needed to
ensure that it makes all the same decisions as our configure.) It's not
for users and should not be installed.

If you want a pkgconfig file, just use PETSc.pc. Or use FindPETSc.cmake.

[Arne Morten Kvarving]

Yes that is the file. Cmake is beautiful for configuration, python is a mess - all is in the eye of the beholder. I have my answer. I will patch as long as the file exists and deal with a better way when I have to. The fact that the file is named, and looks like, a cmake config mode file had me confused.

-------- Opprinnelig melding --------
Fra: Jed Brown <***@jedbrown.org>
Dato: 13.10.2015 18.15 (GMT+01:00)
Til: Satish Balay <***@mcs.anl.gov>, Arne Morten Kvarving <***@sintef.no>
Ko: petsc-users <petsc-***@mcs.anl.gov>
Emne: Re: [petsc-users] petsc cmake config - BUILD_SHARED_LIBS

Satish Balay <***@mcs.anl.gov> writes:

> As mentioned - PETScConfig.cmake is primarily for building PETSc - and
> not equivalent to .pc file

def dumpCMakeConfig(self):
'''
Writes configuration-specific values to ${PETSC_ARCH}/lib/petsc/conf/PETScConfig.cmake.
This file is private to PETSc and should not be included by third parties
(a suitable file can be produced later by CMake, but this is not it).
'''

Arne, is this the file you are talking about? It is part of the legacy
cmake build and is used to hold the various ARCH-specific variables when
building PETSc. (Note that this build does not use CMake for configure
since CMake is disgusting for that purpose and also because we needed to
ensure that it makes all the same decisions as our configure.) It's not
for users and should not be installed.

If you want a pkgconfig file, just use PETSc.pc. Or use FindPETSc.cmake.

[Matthew Knepley]

On Tue, Oct 13, 2015 at 11:26 AM, Arne Morten Kvarving <
***@sintef.no> wrote:

> Yes that is the file. Cmake is beautiful for configuration, python is a
> mess - all is in the eye of the beholder. I have my answer. I will patch as
> long as the file exists and deal with a
>

No, some things are actually better than other things. This is why its
engineering and not art appreciation.

Matt


> better way when I have to. The fact that the file is named, and looks
> like, a cmake config mode file had me confused.
>
> -------- Opprinnelig melding --------
> Fra: Jed Brown <***@jedbrown.org>
> Dato: 13.10.2015 18.15 (GMT+01:00)
> Til: Satish Balay <***@mcs.anl.gov>, Arne Morten Kvarving <
> ***@sintef.no>
> Ko: petsc-users <petsc-***@mcs.anl.gov>
> Emne: Re: [petsc-users] petsc cmake config - BUILD_SHARED_LIBS
>
> Satish Balay <***@mcs.anl.gov> writes:
>
> > As mentioned - PETScConfig.cmake is primarily for building PETSc - and
> > not equivalent to .pc file
>
> def dumpCMakeConfig(self):
> '''
> Writes configuration-specific values to
> ${PETSC_ARCH}/lib/petsc/conf/PETScConfig.cmake.
> This file is private to PETSc and should not be included by third
> parties
> (a suitable file can be produced later by CMake, but this is not it).
> '''
>
> Arne, is this the file you are talking about? It is part of the legacy
> cmake build and is used to hold the various ARCH-specific variables when
> building PETSc. (Note that this build does not use CMake for configure
> since CMake is disgusting for that purpose and also because we needed to
> ensure that it makes all the same decisions as our configure.) It's not
> for users and should not be installed.
>
> If you want a pkgconfig file, just use PETSc.pc. Or use FindPETSc.cmake.
>



--
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

[Arne Morten Kvarving]

> No, some things are actually better than other things. This is why its engineering and not art appreciation.

let me rephrase that. it depends on your position. i'm sure you have sound, technical reasons for reinventing the wheel. but from a user's point of view that sucks, because now i have to learn how to operate (or more relevant; change) a new wheel. with cmake or automake, it is (well, ideally) learn once, apply everywhere. with custom solutions, you get to spend time learning stuff all over again, stuff which cannot be reapplied elsewhere.

ref the thing here that happened with my misunderstanding of the purpose of that config file. whenever i see a <Package>Config.cmake it is the cmake config mode file for <Package>. it did not occur to me that it could be anything else, because i have never seen it be anything else in any other pieces of software.

not trying to pick a fight. just clarifying what i meant.

[Matthew Knepley]

On Tue, Oct 13, 2015 at 1:12 PM, Arne Morten Kvarving <
***@sintef.no> wrote:

> > No, some things are actually better than other things. This is why its
> engineering and not art appreciation.
>
> let me rephrase that. it depends on your position. i'm sure you have
> sound, technical reasons for reinventing the wheel. but from a user's point
> of view that sucks, because now i have to learn how to operate (or more
> relevant; change) a new wheel. with cmake or automake, it is (well,
> ideally) learn once, apply everywhere. with custom solutions, you get to
> spend time learning stuff all over again, stuff which cannot be reapplied
> elsewhere.
>
> ref the thing here that happened with my misunderstanding of the purpose
> of that config file. whenever i see a <Package>Config.cmake it is the cmake
> config mode file for <Package>. it did not occur to me that it could be
> anything else, because i have never seen it be anything else in any other
> pieces of software.
>

Yes, we need to change the name of that. Its very confusing and no longer
used.

We tried very hard to use CMake, but it was woefully inadequate. We wrote a
long and detailed analysis
of the shortcomings, posted it to the PETSc list, and set it to the
developers. Nothing has been fixed, and
thus we have moved on.

Matt


> not trying to pick a fight. just clarifying what i meant.
>



--
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

[Barry Smith]

> On Oct 13, 2015, at 1:15 PM, Matthew Knepley <***@gmail.com> wrote:
>
> On Tue, Oct 13, 2015 at 1:12 PM, Arne Morten Kvarving <***@sintef.no> wrote:
> > No, some things are actually better than other things. This is why its engineering and not art appreciation.
>
> let me rephrase that. it depends on your position. i'm sure you have sound, technical reasons for reinventing the wheel. but from a user's point of view that sucks, because now i have to learn how to operate (or more relevant; change) a new wheel. with cmake or automake, it is (well, ideally) learn once, apply everywhere. with custom solutions, you get to spend time learning stuff all over again, stuff which cannot be reapplied elsewhere.
>
> ref the thing here that happened with my misunderstanding of the purpose of that config file. whenever i see a <Package>Config.cmake it is the cmake config mode file for <Package>. it did not occur to me that it could be anything else, because i have never seen it be anything else in any other pieces of software.
>
> Yes, we need to change the name of that. Its very confusing and no longer used.

Satish,

Can you please change the name of this file so it doesn't cause confusion in the future. Put something in the name to clearly indicate it is not a <Package>Config.cmake for people to use. Perhaps DoNotUseThisInternalToPetscOnlyConfig.cmake


Thanks

Barry

>
> We tried very hard to use CMake, but it was woefully inadequate. We wrote a long and detailed analysis
> of the shortcomings, posted it to the PETSc list, and set it to the developers. Nothing has been fixed, and
> thus we have moved on.
>
> Matt
>
> not trying to pick a fight. just clarifying what i meant.
>
>
>
> --
> 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

[Satish Balay]

On Tue, 13 Oct 2015, Barry Smith wrote:

> > ref the thing here that happened with my misunderstanding of the purpose of that config file. whenever i see a <Package>Config.cmake it is the cmake config mode file for <Package>. it did not occur to me that it could be anything else, because i have never seen it be anything else in any other pieces of software.
> >
> > Yes, we need to change the name of that. Its very confusing and no longer used.
>
> Satish,
>
> Can you please change the name of this file so it doesn't cause confusion in the future. Put something in the name to clearly indicate it is not a <Package>Config.cmake for people to use. Perhaps DoNotUseThisInternalToPetscOnlyConfig.cmake

Which do you prefer:

PETScCmakeBuild.conf
or
PETScBuild.cmake

At some point - we might want to completely remove the cmake build related code..

Satish

[Matthew Knepley]

On Tue, Oct 13, 2015 at 1:39 PM, Satish Balay <***@mcs.anl.gov> wrote:

> On Tue, 13 Oct 2015, Barry Smith wrote:
>
> > > ref the thing here that happened with my misunderstanding of the
> purpose of that config file. whenever i see a <Package>Config.cmake it is
> the cmake config mode file for <Package>. it did not occur to me that it
> could be anything else, because i have never seen it be anything else in
> any other pieces of software.
> > >
> > > Yes, we need to change the name of that. Its very confusing and no
> longer used.
> >
> > Satish,
> >
> > Can you please change the name of this file so it doesn't cause
> confusion in the future. Put something in the name to clearly indicate it
> is not a <Package>Config.cmake for people to use. Perhaps
> DoNotUseThisInternalToPetscOnlyConfig.cmake
>
> Which do you prefer:
>
> PETScCmakeBuild.conf
> or
> PETScBuild.cmake
>

PETScBuildInternal.cmake


> At some point - we might want to completely remove the cmake build related
> code..


I am for that right now. "There can be only one"

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

[Satish Balay]

On Tue, 13 Oct 2015, Matthew Knepley wrote:

>
> PETScBuildInternal.cmake

https://bitbucket.org/petsc/petsc/commits/724dfae7c63ee3ea425936afc826da2605377f15

Pushed to master.

thanks,
Satish

[Satish Balay]

On Tue, 13 Oct 2015, Satish Balay wrote:

> [This mode is deprecated - and not properly tested - and I see its currenty broken]

>>>>>>>>>>>>
Executing: ['/usr/bin/cmake', '--version']
stdout:
cmake version 3.3.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
Could not parse CMake version: cmake version 3.3.2
CMake suite maintained and supported by Kitware (kitware.com/cmake)., disabling cmake build option
CMake configuration was unsuccessful
<<<<<<<<<<<<<

Jed,

If this looks ok - I can push to maint.
[works for me with cmake 2.8.12 and 3.3.2]

Satish

--------
diff --git a/config/cmakeboot.py b/config/cmakeboot.py
index 64accff..5818c14 100755
--- a/config/cmakeboot.py
+++ b/config/cmakeboot.py
@@ -77,7 +77,7 @@ class PETScMaker(script.Script):

output,error,retcode = self.executeShellCommand([self.cmake.cmake, '--version'], checkCommand=noCheck, log=log)
import re
- m = re.match(r'cmake version (.+)$', output)
+ m = re.match(r'cmake version (.+)', output)
if not m:
self.logPrint('Could not parse CMake version: %s, disabling cmake build option' % output)
return False

[Jed Brown]

Satish Balay <***@mcs.anl.gov> writes:
> If this looks ok - I can push to maint.
> [works for me with cmake 2.8.12 and 3.3.2]

That's fine. $ only matches at the end of the string unless flags=re.M
is set.

> --------
> diff --git a/config/cmakeboot.py b/config/cmakeboot.py
> index 64accff..5818c14 100755
> --- a/config/cmakeboot.py
> +++ b/config/cmakeboot.py
> @@ -77,7 +77,7 @@ class PETScMaker(script.Script):
>
> output,error,retcode = self.executeShellCommand([self.cmake.cmake, '--version'], checkCommand=noCheck, log=log)
> import re
> - m = re.match(r'cmake version (.+)$', output)
> + m = re.match(r'cmake version (.+)', output)
> if not m:
> self.logPrint('Could not parse CMake version: %s, disabling cmake build option' % output)
> return False

[Satish Balay]

pushed to maint.

thanks,
satish

On Tue, 13 Oct 2015, Jed Brown wrote:

> Satish Balay <***@mcs.anl.gov> writes:
> > If this looks ok - I can push to maint.
> > [works for me with cmake 2.8.12 and 3.3.2]
>
> That's fine. $ only matches at the end of the string unless flags=re.M
> is set.
>
> > --------
> > diff --git a/config/cmakeboot.py b/config/cmakeboot.py
> > index 64accff..5818c14 100755
> > --- a/config/cmakeboot.py
> > +++ b/config/cmakeboot.py
> > @@ -77,7 +77,7 @@ class PETScMaker(script.Script):
> >
> > output,error,retcode = self.executeShellCommand([self.cmake.cmake, '--version'], checkCommand=noCheck, log=log)
> > import re
> > - m = re.match(r'cmake version (.+)$', output)
> > + m = re.match(r'cmake version (.+)', output)
> > if not m:
> > self.logPrint('Could not parse CMake version: %s, disabling cmake build option' % output)
> > return False
>
>

[Arne Morten Kvarving]

I can certainly can use the find rule but the fact that it isnt part of the petsc distro complicates things more for me than the patch does.

-------- Opprinnelig melding --------
Fra: Satish Balay <***@mcs.anl.gov>
Dato: 13.10.2015 18.13 (GMT+01:00)
Til: Arne Morten Kvarving <***@sintef.no>
Ko: petsc-users <petsc-***@mcs.anl.gov>
Emne: Re: [petsc-users] petsc cmake config - BUILD_SHARED_LIBS

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

[Jed Brown]

Arne Morten Kvarving <***@sintef.no> writes:

> I can certainly can use the find rule but the fact that it isnt part
> of the petsc distro complicates things more for me than the patch
> does.

PETSC_ARCH/lib/petsc/conf/PETScConfig.cmake is not for you. It is not
installed (so your code won't work for prefix installs) and we could
delete it from the build tree at any time. It is a private
implementation detail of PETSc's legacy cmake build, which is not used
any more because gnumake is so much better.

If you want functionality analogous to pkgconfig, use PETSc.pc.