Re: [petsc-dev] CMake on Catalina

[Satish Balay via petsc-dev]

Yeah - there as prior e-mail on OSX discrepancies.

Note all 3 boxes are on 10.15 - and Xcode-11+. Is 10.14 SDK a reference to 
Xcode-10?

Satish
---

balay@jpro^~ $ xcodebuild -version
Xcode 11.3.1
Build version 11C504

The other tow boxes are now giving:
ipro:~ balay$ xcodebuild -V
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer 
directory '/Library/Developer/CommandLineTools' is a command line tools instance
balay@kpro ~ % xcodebuild -version
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer 
directory '/Library/Developer/CommandLineTools' is a command line tools instance


ipro:~ balay$ clang --version
Apple clang version 11.0.3 (clang-1103.0.32.59)
balay@jpro^~ $ clang --version
Apple clang version 11.0.0 (clang-1100.0.33.17)
balay@kpro ~ % clang --version
Apple clang version 11.0.0 (clang-1100.0.33.8)


Satish

On Sat, 18 Apr 2020, Pierre Jolivet wrote:

> This looks similar to last month message "[petsc-maint] GNU toolchain on 
> macOS”, you probably need to go back to the 10.14 SDK.
> 
> Thanks,
> Pierre
> 
> > On 18 Apr 2020, at 3:59 AM, Satish Balay via petsc-dev 
> >  wrote:
> > 
> > I just did the following build on 3 of the OSX test boxes. [with brew gcc 
> > etc..]
> > 
> > balay@jpro^~/petsc(maint) $ ./configure --with-mpi=0 CC=gcc-9 CXX=g++-9 
> > FC=gfortran-9 --download-cmake
> > 
> > Worked on 2 of them.
> > 
> > The 3rd failed with PETSc configure errors.
> > 
> > As far as I can tell - all 3 systems should be the same [latest, OSX, xcode 
> > updated at the same time, all have command line tools installed etc..] - 
> > but they are not  - and I don't understand why.
> > 
> > Satish
> > 
> > -
> > 
> > 
> > TEST checkLibC from 
> > config.setCompilers(/Users/balay/petsc/config/BuildSystem/config/setCompilers.py:1510)
> > TESTING: checkLibC from 
> > config.setCompilers(config/BuildSystem/config/setCompilers.py:1510)
> >  Test whether we need to explicitly include libc in shared linking
> >   - Mac OSX requires an explicit reference to libc for shared linking
> > Running Executable WITHOUT threads to time it out
> > Executing: gcc-9 -c -o 
> > /var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GRzCKQ/config.setCompilers/conftest.o
> >  -I/var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GR\
> > zCKQ/config.setCompilers   
> > /var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GRzCKQ/config.setCompilers/conftest.c
> >  
> > Possible ERROR while running compiler: exit code 1
> > stderr:
> > In file included from 
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/wait.h:110,
> > from 
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/stdlib.h:66,
> > from 
> > /var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GRzCKQ/config.setCompilers/conftest.c:3:
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/resource.h:
> >  In function 'getiopolicy_np':
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/resource.h:443:34:
> >  error: expected declaration specifiers before '__OSX_AVAILABLE_STARTING'
> >  443 | int getiopolicy_np(int, int) 
> > __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
> >  |  ^~~~
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/resource.h:449:39:
> >  error: expected '=', ',', ';', 'asm' or '__attribute__' before 
> > '__OSX_AVAILABLE_STA\
> > RTING'
> >  449 | int setiopolicy_np(int, int, int) 
> > __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
> >  |   ^~~~
> > In file included from 
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/libkern/_OSByteOrder.h:66,
> > from 
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/_endian.h:130,
> > from 
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/i386/endian.h:99,
> > from 
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/machine/endian.h:35,
> > from 
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/wait.h:186,
> > from 
> > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/stdlib.h:66,
> > from 
> > /var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GRzCKQ/config.setCompilers/conftest.c:3:
> > 
> > 
> > On Fri, 17 Apr 2020, Matthew Knepley wrote:
> > 
> >> CMake itself. On Catalina, the SSL/TLS headers use special syntax that only
> >> Clang can parse.
> >> You should check for this in the configure stage, but they do not. The
> >> response for the error
> >> reports on the CMake Github was that you should not be building on Apple
> 

Re: [petsc-dev] CMake on Catalina

[Pierre Jolivet]

This looks similar to last month message "[petsc-maint] GNU toolchain on 
macOS”, you probably need to go back to the 10.14 SDK.

Thanks,
Pierre

> On 18 Apr 2020, at 3:59 AM, Satish Balay via petsc-dev 
>  wrote:
> 
> I just did the following build on 3 of the OSX test boxes. [with brew gcc 
> etc..]
> 
> balay@jpro^~/petsc(maint) $ ./configure --with-mpi=0 CC=gcc-9 CXX=g++-9 
> FC=gfortran-9 --download-cmake
> 
> Worked on 2 of them.
> 
> The 3rd failed with PETSc configure errors.
> 
> As far as I can tell - all 3 systems should be the same [latest, OSX, xcode 
> updated at the same time, all have command line tools installed etc..] - but 
> they are not  - and I don't understand why.
> 
> Satish
> 
> -
> 
> 
> TEST checkLibC from 
> config.setCompilers(/Users/balay/petsc/config/BuildSystem/config/setCompilers.py:1510)
> TESTING: checkLibC from 
> config.setCompilers(config/BuildSystem/config/setCompilers.py:1510)
>  Test whether we need to explicitly include libc in shared linking
>   - Mac OSX requires an explicit reference to libc for shared linking
> Running Executable WITHOUT threads to time it out
> Executing: gcc-9 -c -o 
> /var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GRzCKQ/config.setCompilers/conftest.o
>  -I/var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GR\
> zCKQ/config.setCompilers   
> /var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GRzCKQ/config.setCompilers/conftest.c
>  
> Possible ERROR while running compiler: exit code 1
> stderr:
> In file included from 
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/wait.h:110,
> from 
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/stdlib.h:66,
> from 
> /var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GRzCKQ/config.setCompilers/conftest.c:3:
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/resource.h:
>  In function 'getiopolicy_np':
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/resource.h:443:34:
>  error: expected declaration specifiers before '__OSX_AVAILABLE_STARTING'
>  443 | int getiopolicy_np(int, int) __OSX_AVAILABLE_STARTING(__MAC_10_5, 
> __IPHONE_2_0);
>  |  ^~~~
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/resource.h:449:39:
>  error: expected '=', ',', ';', 'asm' or '__attribute__' before 
> '__OSX_AVAILABLE_STA\
> RTING'
>  449 | int setiopolicy_np(int, int, int) 
> __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
>  |   ^~~~
> In file included from 
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/libkern/_OSByteOrder.h:66,
> from 
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/_endian.h:130,
> from 
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/i386/endian.h:99,
> from 
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/machine/endian.h:35,
> from 
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/wait.h:186,
> from 
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/stdlib.h:66,
> from 
> /var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GRzCKQ/config.setCompilers/conftest.c:3:
> 
> 
> On Fri, 17 Apr 2020, Matthew Knepley wrote:
> 
>> CMake itself. On Catalina, the SSL/TLS headers use special syntax that only
>> Clang can parse.
>> You should check for this in the configure stage, but they do not. The
>> response for the error
>> reports on the CMake Github was that you should not be building on Apple
>> with something that
>> won't parse some of the Apple headers. This seems like an abdication of
>> responsibility to me.
>> 
>>   Matt
>> 
>> On Fri, Apr 17, 2020 at 7:07 PM Satish Balay  wrote:
>> 
>>> Build cmake or a package using cmake?
>>> 
>>> balay@sb /home/balay/petsc (master=)
>>> $ grep download-cmake config/examples/arch-ci-osx-*
>>> config/examples/arch-ci-osx-cxx-cmplx-pkgs-dbg.py:  '--download-cmake=1',
>>> config/examples/arch-ci-osx-cxx-pkgs-opt.py:  '--download-cmake=1',
>>> config/examples/arch-ci-osx-cxx-pkgs-opt.py:  '--download-cmake=1',
>>> config/examples/arch-ci-osx-xsdk-opt.py:  '--download-cmake=1',
>>> 
>>> download-cmake works fine on all our OSX test boxes [they are on Catalina]
>>> 
>>> balay@kpro petsc % sw_vers
>>> ProductName:Mac OS X
>>> ProductVersion: 10.15.3
>>> BuildVersion:   19D76
>>> 
>>> And I have cmake installed via brew on these boxes.
>>> 
>>> Satish
>>> 
>>> On Fri, 17 Apr 2020, Matthew Knepley wrote:
>>> 
 I have just spent hours trying to build CMake on Catalina. This is not a
 configure system. I finally had to just 

Re: [petsc-dev] CMake on Catalina

[Satish Balay via petsc-dev]

I just did the following build on 3 of the OSX test boxes. [with brew gcc etc..]

balay@jpro^~/petsc(maint) $ ./configure --with-mpi=0 CC=gcc-9 CXX=g++-9 
FC=gfortran-9 --download-cmake

Worked on 2 of them.

The 3rd failed with PETSc configure errors.

As far as I can tell - all 3 systems should be the same [latest, OSX, xcode 
updated at the same time, all have command line tools installed etc..] - but 
they are not  - and I don't understand why.

Satish

-


TEST checkLibC from 
config.setCompilers(/Users/balay/petsc/config/BuildSystem/config/setCompilers.py:1510)
TESTING: checkLibC from 
config.setCompilers(config/BuildSystem/config/setCompilers.py:1510)
  Test whether we need to explicitly include libc in shared linking
   - Mac OSX requires an explicit reference to libc for shared linking
Running Executable WITHOUT threads to time it out
Executing: gcc-9 -c -o 
/var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GRzCKQ/config.setCompilers/conftest.o
 -I/var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GR\
zCKQ/config.setCompilers   
/var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GRzCKQ/config.setCompilers/conftest.c
 
Possible ERROR while running compiler: exit code 1
stderr:
In file included from 
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/wait.h:110,
 from 
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/stdlib.h:66,
 from 
/var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GRzCKQ/config.setCompilers/conftest.c:3:
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/resource.h:
 In function 'getiopolicy_np':
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/resource.h:443:34:
 error: expected declaration specifiers before '__OSX_AVAILABLE_STARTING'
  443 | int getiopolicy_np(int, int) __OSX_AVAILABLE_STARTING(__MAC_10_5, 
__IPHONE_2_0);
  |  ^~~~
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/resource.h:449:39:
 error: expected '=', ',', ';', 'asm' or '__attribute__' before 
'__OSX_AVAILABLE_STA\
RTING'
  449 | int setiopolicy_np(int, int, int) 
__OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
  |   ^~~~
In file included from 
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/libkern/_OSByteOrder.h:66,
 from 
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/_endian.h:130,
 from 
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/i386/endian.h:99,
 from 
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/machine/endian.h:35,
 from 
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/sys/wait.h:186,
 from 
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/stdlib.h:66,
 from 
/var/folders/xk/v0fd809s2y7b3x8bp05l2nwwgq/T/petsc-GRzCKQ/config.setCompilers/conftest.c:3:


On Fri, 17 Apr 2020, Matthew Knepley wrote:

> CMake itself. On Catalina, the SSL/TLS headers use special syntax that only
> Clang can parse.
> You should check for this in the configure stage, but they do not. The
> response for the error
> reports on the CMake Github was that you should not be building on Apple
> with something that
> won't parse some of the Apple headers. This seems like an abdication of
> responsibility to me.
> 
>Matt
> 
> On Fri, Apr 17, 2020 at 7:07 PM Satish Balay  wrote:
> 
> > Build cmake or a package using cmake?
> >
> > balay@sb /home/balay/petsc (master=)
> > $ grep download-cmake config/examples/arch-ci-osx-*
> > config/examples/arch-ci-osx-cxx-cmplx-pkgs-dbg.py:  '--download-cmake=1',
> > config/examples/arch-ci-osx-cxx-pkgs-opt.py:  '--download-cmake=1',
> > config/examples/arch-ci-osx-cxx-pkgs-opt.py:  '--download-cmake=1',
> > config/examples/arch-ci-osx-xsdk-opt.py:  '--download-cmake=1',
> >
> > download-cmake works fine on all our OSX test boxes [they are on Catalina]
> >
> > balay@kpro petsc % sw_vers
> > ProductName:Mac OS X
> > ProductVersion: 10.15.3
> > BuildVersion:   19D76
> >
> > And I have cmake installed via brew on these boxes.
> >
> > Satish
> >
> > On Fri, 17 Apr 2020, Matthew Knepley wrote:
> >
> > > I have just spent hours trying to build CMake on Catalina. This is not a
> > > configure system. I finally had to just comment out a bunch of source
> > files
> > > in their build system, and define out a bunch of code. I can't believe
> > this
> > > works anywhere.
> > >
> > >Matt
> > >
> > >
> >
> >
> 
> 

Re: [petsc-dev] CMake on Catalina

[Matthew Knepley]

CMake itself. On Catalina, the SSL/TLS headers use special syntax that only
Clang can parse.
You should check for this in the configure stage, but they do not. The
response for the error
reports on the CMake Github was that you should not be building on Apple
with something that
won't parse some of the Apple headers. This seems like an abdication of
responsibility to me.

   Matt

On Fri, Apr 17, 2020 at 7:07 PM Satish Balay  wrote:

> Build cmake or a package using cmake?
>
> balay@sb /home/balay/petsc (master=)
> $ grep download-cmake config/examples/arch-ci-osx-*
> config/examples/arch-ci-osx-cxx-cmplx-pkgs-dbg.py:  '--download-cmake=1',
> config/examples/arch-ci-osx-cxx-pkgs-opt.py:  '--download-cmake=1',
> config/examples/arch-ci-osx-cxx-pkgs-opt.py:  '--download-cmake=1',
> config/examples/arch-ci-osx-xsdk-opt.py:  '--download-cmake=1',
>
> download-cmake works fine on all our OSX test boxes [they are on Catalina]
>
> balay@kpro petsc % sw_vers
> ProductName:Mac OS X
> ProductVersion: 10.15.3
> BuildVersion:   19D76
>
> And I have cmake installed via brew on these boxes.
>
> Satish
>
> On Fri, 17 Apr 2020, Matthew Knepley wrote:
>
> > I have just spent hours trying to build CMake on Catalina. This is not a
> > configure system. I finally had to just comment out a bunch of source
> files
> > in their build system, and define out a bunch of code. I can't believe
> this
> > works anywhere.
> >
> >Matt
> >
> >
>
>

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

Re: [petsc-dev] CMake on Catalina

[Satish Balay via petsc-dev]

Build cmake or a package using cmake?

balay@sb /home/balay/petsc (master=)
$ grep download-cmake config/examples/arch-ci-osx-*
config/examples/arch-ci-osx-cxx-cmplx-pkgs-dbg.py:  '--download-cmake=1',
config/examples/arch-ci-osx-cxx-pkgs-opt.py:  '--download-cmake=1',
config/examples/arch-ci-osx-cxx-pkgs-opt.py:  '--download-cmake=1',
config/examples/arch-ci-osx-xsdk-opt.py:  '--download-cmake=1',

download-cmake works fine on all our OSX test boxes [they are on Catalina]

balay@kpro petsc % sw_vers 
ProductName:Mac OS X
ProductVersion: 10.15.3
BuildVersion:   19D76

And I have cmake installed via brew on these boxes.

Satish

On Fri, 17 Apr 2020, Matthew Knepley wrote:

> I have just spent hours trying to build CMake on Catalina. This is not a
> configure system. I finally had to just comment out a bunch of source files
> in their build system, and define out a bunch of code. I can't believe this
> works anywhere.
> 
>Matt
> 
> 

Re: [petsc-dev] CMake on Catalina

[huabel via petsc-dev]

CMake is a great tool,  

> On Apr 18, 2020, at 06:36, Matthew Knepley  wrote:
> 
> I have just spent hours trying to build CMake on Catalina. This is not a 
> configure system. I finally had to just comment out a bunch of source files 
> in their build system, and define out a bunch of code. I can't believe this 
> works anywhere.
> 
>Matt
> 
> -- 
> 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/ 

[petsc-dev] CMake on Catalina

[Matthew Knepley]

I have just spent hours trying to build CMake on Catalina. This is not a
configure system. I finally had to just comment out a bunch of source files
in their build system, and define out a bunch of code. I can't believe this
works anywhere.

   Matt

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

[petsc-dev] CMake

[Matthew Knepley]

Can we remove all packages that use CMake before the next release?

See also
"/PETSc3/petsc/petsc-pylith/arch-next-debug/externalpackages/hg.eigen/build/CMakeFiles/CMakeOutput.log".CMake
Error at
/PETSc3/petsc/petsc-pylith/arch-pylith-debug/share/cmake-3.0/Modules/Platform/Darwin.cmake:211
(message):

  CMAKE_OSX_DEPLOYMENT_TARGET is '10.5' but CMAKE_OSX_SYSROOT:


   ""


  is not set to a MacOSX SDK with a recognized version.  Either set

  CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to

  empty.

I hate them.

   Matt

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

Re: [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" <gn...@cam.ac.uk>
> À: "Franck Houssen" <franck.hous...@inria.fr>
> Cc: "Matthew Knepley" <knep...@gmail.com>, "petsc-dev" <petsc-dev@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.hous...@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=file-view-default
> 
> Garth
> 
> > Franck
> >
> > ____
> >
> > De: "Matthew Knepley" <knep...@gmail.com>
> > À: "Franck Houssen" <franck.hous...@inria.fr>
> > Cc: "petsc-dev" <petsc-dev@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.hous...@inria.fr>
> > wrote:
> >>
> >> - Mail original -
> >> > De: "Satish Balay" <ba...@mcs.anl.gov>
> >> > À: "Franck Houssen" <franck.hous...@inria.fr>
> >> > Cc: "petsc-dev" <petsc-dev@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 

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

[Garth N. Wells]

On 7 November 2017 at 09:17, Franck Houssen <franck.hous...@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=file-view-default

Garth

> Franck
>
> 
>
> De: "Matthew Knepley" <knep...@gmail.com>
> À: "Franck Houssen" <franck.hous...@inria.fr>
> Cc: "petsc-dev" <petsc-dev@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.hous...@inria.fr>
> wrote:
>>
>> - Mail original -
>> > De: "Satish Balay" <ba...@mcs.anl.gov>
>> > À: "Franck Houssen" <franck.hous...@inria.fr>
>> > Cc: "petsc-dev" <petsc-dev@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/
>
>

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

[Franck Houssen]

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" <knep...@gmail.com>
> À: "Franck Houssen" <franck.hous...@inria.fr>
> Cc: "petsc-dev" <petsc-dev@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.hous...@inria.fr >
> wrote:

> > - Mail original -
> 
> > > De: "Satish Balay" < ba...@mcs.anl.gov >
> 
> > > À: "Franck Houssen" < franck.hous...@inria.fr >
> 
> > > Cc: "petsc-dev" < petsc-dev@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/

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

[Matthew Knepley]

On Mon, Nov 6, 2017 at 12:49 PM, Franck Houssen <franck.hous...@inria.fr>
wrote:

> - Mail original -
> > De: "Satish Balay" <ba...@mcs.anl.gov>
> > À: "Franck Houssen" <franck.hous...@inria.fr>
> > Cc: "petsc-dev" <petsc-dev@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 : 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. 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/ <http://www.caam.rice.edu/~mk51/>

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

[Franck Houssen]

- Mail original -
> De: "Satish Balay" <ba...@mcs.anl.gov>
> À: "Franck Houssen" <franck.hous...@inria.fr>
> Cc: "petsc-dev" <petsc-dev@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 : 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.

> Satish
> 

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

[Satish Balay]

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

Satish

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

[Franck Houssen]

Looks like you had a bad experience with CMake up to a point of no return 
(probably a shame, but, I can understand that !).
I will use pkg-config: that's fine to me. I was just trying to help here for 
sake of community ! No more, no less !

Franck

- Mail original -
> De: "Satish Balay" 
> Its equivalent to assuming:

Yes ! Your friend let you the keys of his car. The car has no wheel. Why did he 
gave you his keys ?!... :D (joking)

> if 'makefile' exists 'make all && make install' will work.

> > > > Porting a configuration from our Python (BuildSystem) to CMake for
> > > > cross-compilation and all the optional dependencies would be monumental
> > > > task and would result in a portability regression for systems where
> > > > platform files are not yet available.

Yes, you are right. Here is a few solutions you may want to look at (bundle 
attached - Read commit message)

commit 4ae847ecd17ca4d8cbe5b44709d341a568431e11 (HEAD -> cmake)
Author: Franck HOUSSEN 
Date:   Mon Nov 6 08:20:14 2017 +0100

CMake: fix dependencies order (NOT yet working - WIP).

TODO: to get that to work, a simple solution could be to
modify "./configure" such that it creates:
.../externalpackages/00.f2cblaslapack-3.4.2.q3
.../externalpackages/01.scalapack-2.0.2
instead of what it does currently:
.../externalpackages/f2cblaslapack-3.4.2.q3
.../externalpackages/scalapack-2.0.2

This way GLOB_RECURSE comes with the expected link order.

Now, the last problem is reconfiguring. To fix that, a simple
solution could be to attribute a (hard-coded) number to each
package in such a way that if a number is greater than yours,
you don't depend on it (simply list ALL possible packages and
order them by dependencies). For instance, first configure with
--download-blas --download-lapack --with-mpi=...
--download-scalapack and get:
.../externalpackages/00.f2cblaslapack-3.4.2.q3
.../externalpackages/05.scalapack-2.0.2
Now add --download-mpi, and get:
.../externalpackages/00.f2cblaslapack-3.4.2.q3
.../externalpackages/03.openmpi
.../externalpackages/05.scalapack-2.0.2

Reconfiguring can this way add dependencies interleaved in the
existing set of dependencies.


> > > > 
> > > > > More important: getting find_package to work will be much more
> > > > > reliable than resorting to FindPETSc.cmake (often KO as 
> > > > > architecture/OS specific...).


cmake.bundle
Description: Binary data

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

[Smith, Barry F.]

> On Nov 5, 2017, at 8:01 AM, Jed Brown  wrote:
> 
>> 
>> Sure - if you hunt arround the PETSc source tree - you will find bunch
>> of stuff.. [but that would be ignoring the primary doc].
>> 
>> Also There was some reason Jed didn't want to strip out the cmake
>> stuff. Perhaps FindPETSc.cmake uses it?
> 
> No, FindPETSc does not use it.  And I would recommend using CMake's
> pkg-config instead of FindPETSc if you have a current version of PETSc.
> 
> I think the reason for not stripping it entirely was that theoretically
> it could be useful for IDE integration and/or a native Windows build.
> Should probably delete it to avoid confusing someone that is grepping
> around.

   Jed, 

 Can you do the strip or tell us exactly what directories and files to 
strip and what rules from the makefiles. It is time to get rid of this 
obscenity since you replaced it with the far better and more reliable version 
that uses gnumake.

Thanks

Barry

> 
> 
> Franck, we've had a number of problems over the years with CMake
> seg-faulting and going into infinite loops in some reconfiguration
> scenarios.  Possible to work around, but we were fielding frequent
> support emails due to CMake bugs and installation problems.  The build
> got faster, more accurate, and simpler when we switched to GNU Make.
> And the support emails stopped.  You're welcome to use CMake, but we are
> not fans.

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

[Franck Houssen]

OK, guys, let's summarize:
- I just say that generating a CMakeLists.txt (that can't be used) IS 
misleading for any users ! :D
- You don't want to deal with CMake: OK, I am fine with that, no problem (I can 
understand that).
- Now I know (!...), I'll stick to pkg-config... Because now I know !

Bonne journée,

Franck

- Mail original -
> De: "Satish Balay" <ba...@mcs.anl.gov>
> À: "Jed Brown" <j...@jedbrown.org>
> Cc: "Franck Houssen" <franck.hous...@inria.fr>, "petsc-dev" 
> <petsc-dev@mcs.anl.gov>
> Envoyé: Dimanche 5 Novembre 2017 17:13:25
> Objet: Re: [petsc-dev] CMake: make, install, find_package ?
> 
> On Sun, 5 Nov 2017, Jed Brown wrote:
> 
> > Franck Houssen <franck.hous...@inria.fr> writes:
> > 
> > > Here is a bundle you can pull for you to have a look (franck/cmake branch
> > > - push KO to the bitbucket as I don't know which loggin/password to
> > > use): take it or leave it ! :D
> > >
> > > On debian, I have a "real" cmake build (not the configure traces) in a
> > > dedicated BUILD directory (make things cleaner).
> > 
> > PETSC_ARCH is a dedicated build directory.
> > 
> > Porting a configuration from our Python (BuildSystem) to CMake for
> > cross-compilation and all the optional dependencies would be monumental
> > task and would result in a portability regression for systems where
> > platform files are not yet available.
> > 
> > > More important: getting find_package to work will be much more reliable
> > > than resorting to FindPETSc.cmake (often KO as architecture/OS
> > > specific...).
> > 
> > Please use the pkg-config file that PETSc generates.
> > 
> > > I would understand you give up with CMake for reason of your own reason
> > > (!)...
> > > But if so, the simple presence of CMakeLists.txt may be misleading
> > > (personal opinion: people can go "let's try to use it".).
> > >
> > > Hope this helps !...
> > >
> > > Franck
> > >
> > > /petsc> ./configure; mkdir BUILD; cd BUILD; cmake
> > > -DPETSc_CMAKE_ARCH=arch-linux2-c-opt -DCMAKE_INSTALL_PREFIX=/tmp/local
> > > ..; make; make install
> 
> And we never supported this build mode - or documented it - or recommended
> it.
> 
> Configure used cmake to generate gnumakefiles [so presumably this step is
> already done]. So the next step would be 'make all-cmake'
> This basically did:
> 
> cd arch-linux2-c-opt && make -j  ${MAKE_NP}
> 
> Check 'ccmake:' target in lib/petsc/conf/rules
> 
> Satish
> 
> 
> > > ...
> > > -- Configuring done
> > > -- Generating done
> > > -- Build files have been written to:
> > > /home/fghoussen/Documents/INRIA/petsc/BUILD
> > > Scanning dependencies of target petsc
> > > [  0%] Building Fortran object
> > > CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o
> > > [  0%] Building Fortran object
> > > CMakeFiles/petsc.dir/src/vec/f90-mod/petscvecmod.F.o
> > > ...
> > >
> > > - Mail original -
> > >> De: "Satish Balay" <ba...@mcs.anl.gov>
> > >> À: "Franck Houssen" <franck.hous...@inria.fr>
> > >> Cc: "petsc-dev" <petsc-dev@mcs.anl.gov>, "Jed Brown" <j...@jedbrown.org>
> > >> Envoyé: Dimanche 5 Novembre 2017 15:52:44
> > >> Objet: Re: [petsc-dev] CMake: make, install, find_package ?
> > >> 
> > >> On Sun, 5 Nov 2017, Franck Houssen wrote:
> > >> 
> > >> > > Or are you having trouble with
> > >> > > https://github.com/jedbrown/cmake-modules/blob/master/FindPETSc.cmake
> > >> > > ?
> > >> > > [and not with PETSc build?]
> > >> > 
> > >> > At first, I was trying to understand why find_package(petsc) was not
> > >> > working.
> > >> > So then, I looked at the way the make/install was done: that lead me
> > >> > to
> > >> > look at the CMakeLists.txt and test it.
> > >> > 
> > >> 
> > >> > > > What did not work for you? Please send relavent logs.
> > >> > 
> > >> > Didn't find mpi.mod.
> > >> > find_package(MPI) was missing: I just added it.
> > >> > Still can push if you want to have a look (?).
> > >> 
> > >> So your primary issue is with FindPETSc.cmake - and the fix you have is
> > >> for
> > >> petsc?
> > >> 
> > >> Sure post the patch or push [where?] and Jed might review..
> > >> 
> > >> Instructions to reproduce the problem will help.
> > >> 
> > >> Satish
> > >> 
> > 
> 

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

[Satish Balay]

On Sun, 5 Nov 2017, Jed Brown wrote:

> Franck Houssen <franck.hous...@inria.fr> writes:
> 
> > Here is a bundle you can pull for you to have a look (franck/cmake branch - 
> > push KO to the bitbucket as I don't know which loggin/password to use): 
> > take it or leave it ! :D
> >
> > On debian, I have a "real" cmake build (not the configure traces) in a 
> > dedicated BUILD directory (make things cleaner).
> 
> PETSC_ARCH is a dedicated build directory.
> 
> Porting a configuration from our Python (BuildSystem) to CMake for
> cross-compilation and all the optional dependencies would be monumental
> task and would result in a portability regression for systems where
> platform files are not yet available.
> 
> > More important: getting find_package to work will be much more reliable 
> > than resorting to FindPETSc.cmake (often KO as architecture/OS specific...).
> 
> Please use the pkg-config file that PETSc generates.
> 
> > I would understand you give up with CMake for reason of your own reason 
> > (!)... 
> > But if so, the simple presence of CMakeLists.txt may be misleading 
> > (personal opinion: people can go "let's try to use it".).
> >
> > Hope this helps !...
> >
> > Franck
> >
> > /petsc> ./configure; mkdir BUILD; cd BUILD; cmake 
> > -DPETSc_CMAKE_ARCH=arch-linux2-c-opt -DCMAKE_INSTALL_PREFIX=/tmp/local ..; 
> > make; make install

And we never supported this build mode - or documented it - or recommended it.

Configure used cmake to generate gnumakefiles [so presumably this step is 
already done]. So the next step would be 'make all-cmake'
This basically did:

cd arch-linux2-c-opt && make -j  ${MAKE_NP}

Check 'ccmake:' target in lib/petsc/conf/rules

Satish


> > ...
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: 
> > /home/fghoussen/Documents/INRIA/petsc/BUILD
> > Scanning dependencies of target petsc
> > [  0%] Building Fortran object 
> > CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o
> > [  0%] Building Fortran object 
> > CMakeFiles/petsc.dir/src/vec/f90-mod/petscvecmod.F.o
> > ...
> >
> > - Mail original -
> >> De: "Satish Balay" <ba...@mcs.anl.gov>
> >> À: "Franck Houssen" <franck.hous...@inria.fr>
> >> Cc: "petsc-dev" <petsc-dev@mcs.anl.gov>, "Jed Brown" <j...@jedbrown.org>
> >> Envoyé: Dimanche 5 Novembre 2017 15:52:44
> >> Objet: Re: [petsc-dev] CMake: make, install, find_package ?
> >> 
> >> On Sun, 5 Nov 2017, Franck Houssen wrote:
> >> 
> >> > > Or are you having trouble with
> >> > > https://github.com/jedbrown/cmake-modules/blob/master/FindPETSc.cmake ?
> >> > > [and not with PETSc build?]
> >> > 
> >> > At first, I was trying to understand why find_package(petsc) was not
> >> > working.
> >> > So then, I looked at the way the make/install was done: that lead me to
> >> > look at the CMakeLists.txt and test it.
> >> > 
> >> 
> >> > > > What did not work for you? Please send relavent logs.
> >> > 
> >> > Didn't find mpi.mod.
> >> > find_package(MPI) was missing: I just added it.
> >> > Still can push if you want to have a look (?).
> >> 
> >> So your primary issue is with FindPETSc.cmake - and the fix you have is for
> >> petsc?
> >> 
> >> Sure post the patch or push [where?] and Jed might review..
> >> 
> >> Instructions to reproduce the problem will help.
> >> 
> >> Satish
> >> 
> 

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

[Jed Brown]

Franck Houssen <franck.hous...@inria.fr> writes:

> Here is a bundle you can pull for you to have a look (franck/cmake branch - 
> push KO to the bitbucket as I don't know which loggin/password to use): take 
> it or leave it ! :D
>
> On debian, I have a "real" cmake build (not the configure traces) in a 
> dedicated BUILD directory (make things cleaner).

PETSC_ARCH is a dedicated build directory.

Porting a configuration from our Python (BuildSystem) to CMake for
cross-compilation and all the optional dependencies would be monumental
task and would result in a portability regression for systems where
platform files are not yet available.

> More important: getting find_package to work will be much more reliable than 
> resorting to FindPETSc.cmake (often KO as architecture/OS specific...).

Please use the pkg-config file that PETSc generates.

> I would understand you give up with CMake for reason of your own reason 
> (!)... 
> But if so, the simple presence of CMakeLists.txt may be misleading (personal 
> opinion: people can go "let's try to use it".).
>
> Hope this helps !...
>
> Franck
>
> /petsc> ./configure; mkdir BUILD; cd BUILD; cmake 
> -DPETSc_CMAKE_ARCH=arch-linux2-c-opt -DCMAKE_INSTALL_PREFIX=/tmp/local ..; 
> make; make install
> ...
> -- Configuring done
> -- Generating done
> -- Build files have been written to: 
> /home/fghoussen/Documents/INRIA/petsc/BUILD
> Scanning dependencies of target petsc
> [  0%] Building Fortran object 
> CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o
> [  0%] Building Fortran object 
> CMakeFiles/petsc.dir/src/vec/f90-mod/petscvecmod.F.o
> ...
>
> - Mail original -
>> De: "Satish Balay" <ba...@mcs.anl.gov>
>> À: "Franck Houssen" <franck.hous...@inria.fr>
>> Cc: "petsc-dev" <petsc-dev@mcs.anl.gov>, "Jed Brown" <j...@jedbrown.org>
>> Envoyé: Dimanche 5 Novembre 2017 15:52:44
>> Objet: Re: [petsc-dev] CMake: make, install, find_package ?
>> 
>> On Sun, 5 Nov 2017, Franck Houssen wrote:
>> 
>> > > Or are you having trouble with
>> > > https://github.com/jedbrown/cmake-modules/blob/master/FindPETSc.cmake ?
>> > > [and not with PETSc build?]
>> > 
>> > At first, I was trying to understand why find_package(petsc) was not
>> > working.
>> > So then, I looked at the way the make/install was done: that lead me to
>> > look at the CMakeLists.txt and test it.
>> > 
>> 
>> > > > What did not work for you? Please send relavent logs.
>> > 
>> > Didn't find mpi.mod.
>> > find_package(MPI) was missing: I just added it.
>> > Still can push if you want to have a look (?).
>> 
>> So your primary issue is with FindPETSc.cmake - and the fix you have is for
>> petsc?
>> 
>> Sure post the patch or push [where?] and Jed might review..
>> 
>> Instructions to reproduce the problem will help.
>> 
>> Satish
>> 

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

[Jed Brown]

Satish Balay  writes:

> On Sun, 5 Nov 2017, Franck Houssen wrote:
>
>> Personal opinion: either you decide to have a fresh look at this (things may 
>> be better now), or, you should unplug the generation of CMakeLists.txt 
>> (misleading). 
>
> Hm - configure prints at the end:
>
> xxx=xxx
>  Configure stage complete. Now build PETSc libraries with (gnumake build):
>make PETSC_DIR=/home/balay/petsc PETSC_ARCH=arch-linux2-c-debug all
> xxx=xxx
>
> So there is no reference to cmake build here - and nothing misleading.
>
> Sure - if you hunt arround the PETSc source tree - you will find bunch
> of stuff.. [but that would be ignoring the primary doc].
>
> Also There was some reason Jed didn't want to strip out the cmake
> stuff. Perhaps FindPETSc.cmake uses it?

No, FindPETSc does not use it.  And I would recommend using CMake's
pkg-config instead of FindPETSc if you have a current version of PETSc.

I think the reason for not stripping it entirely was that theoretically
it could be useful for IDE integration and/or a native Windows build.
Should probably delete it to avoid confusing someone that is grepping
around.


Franck, we've had a number of problems over the years with CMake
seg-faulting and going into infinite loops in some reconfiguration
scenarios.  Possible to work around, but we were fielding frequent
support emails due to CMake bugs and installation problems.  The build
got faster, more accurate, and simpler when we switched to GNU Make.
And the support emails stopped.  You're welcome to use CMake, but we are
not fans.

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

[Franck Houssen]

Here is a bundle you can pull for you to have a look (franck/cmake branch - 
push KO to the bitbucket as I don't know which loggin/password to use): take it 
or leave it ! :D

On debian, I have a "real" cmake build (not the configure traces) in a 
dedicated BUILD directory (make things cleaner).
More important: getting find_package to work will be much more reliable than 
resorting to FindPETSc.cmake (often KO as architecture/OS specific...).

I would understand you give up with CMake for reason of your own reason (!)... 
But if so, the simple presence of CMakeLists.txt may be misleading (personal 
opinion: people can go "let's try to use it".).

Hope this helps !...

Franck

/petsc> ./configure; mkdir BUILD; cd BUILD; cmake 
-DPETSc_CMAKE_ARCH=arch-linux2-c-opt -DCMAKE_INSTALL_PREFIX=/tmp/local ..; 
make; make install
...
-- Configuring done
-- Generating done
-- Build files have been written to: /home/fghoussen/Documents/INRIA/petsc/BUILD
Scanning dependencies of target petsc
[  0%] Building Fortran object 
CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o
[  0%] Building Fortran object 
CMakeFiles/petsc.dir/src/vec/f90-mod/petscvecmod.F.o
...

- Mail original -
> De: "Satish Balay" <ba...@mcs.anl.gov>
> À: "Franck Houssen" <franck.hous...@inria.fr>
> Cc: "petsc-dev" <petsc-dev@mcs.anl.gov>, "Jed Brown" <j...@jedbrown.org>
> Envoyé: Dimanche 5 Novembre 2017 15:52:44
> Objet: Re: [petsc-dev] CMake: make, install, find_package ?
> 
> On Sun, 5 Nov 2017, Franck Houssen wrote:
> 
> > > Or are you having trouble with
> > > https://github.com/jedbrown/cmake-modules/blob/master/FindPETSc.cmake ?
> > > [and not with PETSc build?]
> > 
> > At first, I was trying to understand why find_package(petsc) was not
> > working.
> > So then, I looked at the way the make/install was done: that lead me to
> > look at the CMakeLists.txt and test it.
> > 
> 
> > > > What did not work for you? Please send relavent logs.
> > 
> > Didn't find mpi.mod.
> > find_package(MPI) was missing: I just added it.
> > Still can push if you want to have a look (?).
> 
> So your primary issue is with FindPETSc.cmake - and the fix you have is for
> petsc?
> 
> Sure post the patch or push [where?] and Jed might review..
> 
> Instructions to reproduce the problem will help.
> 
> Satish
> 


cmake.bundle
Description: Binary data

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

[Matthew Knepley]

On Sun, Nov 5, 2017 at 9:37 AM, Franck Houssen <franck.hous...@inria.fr>
wrote:

> --
>
> *De: *"Matthew Knepley" <knep...@gmail.com>
> *À: *"Franck Houssen" <franck.hous...@inria.fr>
> *Cc: *"For users of the development version of PETSc" <
> petsc-dev@mcs.anl.gov>
> *Envoyé: *Dimanche 5 Novembre 2017 15:09:30
> *Objet: *Re: [petsc-dev] CMake: make, install, find_package ?
>
> On Sun, Nov 5, 2017 at 8:57 AM, Franck Houssen <franck.hous...@inria.fr>
> wrote:
>
>> Hello,
>>
>> Does PETSc provide support for CMake ? I would say this is an on-going
>> feature that is not yet fully working, right ?
>>
>> My understanding is that "./configure" generates the CMakeLists.txt. But
>> then, when using cmake, make fails.
>> Is this supposed to work yet ? Or is this on-going dev ? (google is
>> misleading about that, and, not seen anything in the doc)
>>
>
> We supported this a few years ago, but the obscene brokeness of CMake
> makes this impossible, so it is no longer supported.
>
>
> Obscene brokeness ?! What do you mean !?
>

There is a lot of CMake discussion on the list. Searching will turn it up.


> Reminds me Travis-CI when I struggled to upgrade from ubuntu-12, and, had
> to rebuild everything during 45 mins out of the 49 mins slot available !...
> :D
>
> I believe this is a shame (as lots of people use cmake)... But I
> understand 100% the obscene part of the "dark side" ! (I escaped the
> Travis-CI "death star")
> I got that to work in 30-45 minutes (with find_package support): looks
> nice and stable...
> Personal opinion: either you decide to have a fresh look at this (things
> may be better now), or, you should unplug the generation of CMakeLists.txt
> (misleading).
>

We do not suggest this in either the manual or the generated help. People
are free to use it at their own risk.

   Matt


> Franck
>
>
>   Thanks,
>
> Matt
>
>> Franck
>>
>> PS : I got it to work (partially - for petsc, not external packages) on
>> my laptop (debian). I may (?) push I somebody is interested to have a look
>> (on going dev ?).
>>
>
>
>
> --
> 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/ <http://www.caam.rice.edu/~mk51/>
>
>
>


-- 
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/ <http://www.caam.rice.edu/~mk51/>

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

[Satish Balay]

On Sun, 5 Nov 2017, Franck Houssen wrote:

> > Or are you having trouble with
> > https://github.com/jedbrown/cmake-modules/blob/master/FindPETSc.cmake ?
> > [and not with PETSc build?]
> 
> At first, I was trying to understand why find_package(petsc) was not working.
> So then, I looked at the way the make/install was done: that lead me to look 
> at the CMakeLists.txt and test it.
> 

> > > What did not work for you? Please send relavent logs.
> 
> Didn't find mpi.mod.
> find_package(MPI) was missing: I just added it.
> Still can push if you want to have a look (?).

So your primary issue is with FindPETSc.cmake - and the fix you have is for 
petsc?

Sure post the patch or push [where?] and Jed might review..

Instructions to reproduce the problem will help.

Satish

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

[Satish Balay]

On Sun, 5 Nov 2017, Franck Houssen wrote:

> Personal opinion: either you decide to have a fresh look at this (things may 
> be better now), or, you should unplug the generation of CMakeLists.txt 
> (misleading). 

Hm - configure prints at the end:

xxx=xxx
 Configure stage complete. Now build PETSc libraries with (gnumake build):
   make PETSC_DIR=/home/balay/petsc PETSC_ARCH=arch-linux2-c-debug all
xxx=xxx

So there is no reference to cmake build here - and nothing misleading.

Sure - if you hunt arround the PETSc source tree - you will find bunch
of stuff.. [but that would be ignoring the primary doc].

Also There was some reason Jed didn't want to strip out the cmake
stuff. Perhaps FindPETSc.cmake uses it?

Jed can confirm.

Satish

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

[Franck Houssen]

- Mail original -
> De: "Satish Balay" <ba...@mcs.anl.gov>
> À: "petsc-dev" <petsc-dev@mcs.anl.gov>
> Cc: "Franck Houssen" <franck.hous...@inria.fr>
> Envoyé: Dimanche 5 Novembre 2017 15:16:48
> Objet: Re: [petsc-dev] CMake: make, install, find_package ?
> 
> BTW: why are prefering all-cmake build over all-gnumake build?

I have no preference !

> 
> Or are you having trouble with
> https://github.com/jedbrown/cmake-modules/blob/master/FindPETSc.cmake ?
> [and not with PETSc build?]

At first, I was trying to understand why find_package(petsc) was not working.
So then, I looked at the way the make/install was done: that lead me to look at 
the CMakeLists.txt and test it.

> 
> Satish
> 
> On Sun, 5 Nov 2017, Satish Balay wrote:
> 
> > PETSc has 3 modes of building libraries
> > 
> > 1. all-legacy: using legacy makefiles [which uses vanila make in recursive
> > mode]
> > 2. all-cmake: using cmake to generate gnumakefiles
> > 3. all-gnumake: using gnumakefiles
> > 
> > Now all-gnumake build is the default/primary. with it working in all
> > cases - there is no real reason for all-cmake build.
> > 
> > [we still use all-legacy for documentation generation and examples, and a
> > few other cases]
> > 
> > So all-cmake is not tested and unsupported. But the code is still there and
> > is not removed [or updated]
> > 
> > However - I just tired a simple 'all-cmake' build - and that worked.
> > [attaching make.log]
> > 
> > What did not work for you? Please send relavent logs.

Didn't find mpi.mod.
find_package(MPI) was missing: I just added it.
Still can push if you want to have a look (?).

> > 
> > Satish
> > 
> > On Sun, 5 Nov 2017, Franck Houssen wrote:
> > 
> > > Hello,
> > > 
> > > Does PETSc provide support for CMake ? I would say this is an on-going
> > > feature that is not yet fully working, right ?
> > > My understanding is that "./configure" generates the CMakeLists.txt. But
> > > then, when using cmake, make fails.
> > > Is this supposed to work yet ? Or is this on-going dev ? (google is
> > > misleading about that, and, not seen anything in the doc)
> > > 
> > > Franck
> > > 
> > > PS : I got it to work (partially - for petsc, not external packages) on
> > > my laptop (debian). I may (?) push I somebody is interested to have a
> > > look (on going dev ?).
> > > 
> > 
> 
> 

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

[Franck Houssen]

- Mail original -

> De: "Matthew Knepley" <knep...@gmail.com>
> À: "Franck Houssen" <franck.hous...@inria.fr>
> Cc: "For users of the development version of PETSc" <petsc-dev@mcs.anl.gov>
> Envoyé: Dimanche 5 Novembre 2017 15:09:30
> Objet: Re: [petsc-dev] CMake: make, install, find_package ?

> On Sun, Nov 5, 2017 at 8:57 AM, Franck Houssen < franck.hous...@inria.fr >
> wrote:

> > Hello,
> 

> > Does PETSc provide support for CMake ? I would say this is an on-going
> > feature that is not yet fully working, right ?
> 

> > My understanding is that "./configure" generates the CMakeLists.txt. But
> > then, when using cmake, make fails.
> 
> > Is this supposed to work yet ? Or is this on-going dev ? (google is
> > misleading about that, and, not seen anything in the doc)
> 

> We supported this a few years ago, but the obscene brokeness of CMake makes
> this impossible, so it is no longer supported.

Obscene brokeness ?! What do you mean !? 
Reminds me Travis-CI when I struggled to upgrade from ubuntu-12, and, had to 
rebuild everything during 45 mins out of the 49 mins slot available !... :D 

I believe this is a shame (as lots of people use cmake)... But I understand 
100% the obscene part of the "dark side" ! (I escaped the Travis-CI "death 
star") 
I got that to work in 30-45 minutes (with find_package support): looks nice and 
stable... 
Personal opinion: either you decide to have a fresh look at this (things may be 
better now), or, you should unplug the generation of CMakeLists.txt 
(misleading). 

Franck 

> Thanks,

> Matt

> > Franck
> 

> > PS : I got it to work (partially - for petsc, not external packages) on my
> > laptop (debian). I may (?) push I somebody is interested to have a look (on
> > going dev ?).
> 

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

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

[Satish Balay]

BTW: why are prefering all-cmake build over all-gnumake build?

Or are you having trouble with
https://github.com/jedbrown/cmake-modules/blob/master/FindPETSc.cmake ?
[and not with PETSc build?]

Satish

On Sun, 5 Nov 2017, Satish Balay wrote:

> PETSc has 3 modes of building libraries
> 
> 1. all-legacy: using legacy makefiles [which uses vanila make in recursive 
> mode]
> 2. all-cmake: using cmake to generate gnumakefiles
> 3. all-gnumake: using gnumakefiles
> 
> Now all-gnumake build is the default/primary. with it working in all
> cases - there is no real reason for all-cmake build.
> 
> [we still use all-legacy for documentation generation and examples, and a few 
> other cases]
> 
> So all-cmake is not tested and unsupported. But the code is still there and 
> is not removed [or updated]
> 
> However - I just tired a simple 'all-cmake' build - and that worked. 
> [attaching make.log]
> 
> What did not work for you? Please send relavent logs.
> 
> Satish
> 
> On Sun, 5 Nov 2017, Franck Houssen wrote:
> 
> > Hello, 
> > 
> > Does PETSc provide support for CMake ? I would say this is an on-going 
> > feature that is not yet fully working, right ? 
> > My understanding is that "./configure" generates the CMakeLists.txt. But 
> > then, when using cmake, make fails. 
> > Is this supposed to work yet ? Or is this on-going dev ? (google is 
> > misleading about that, and, not seen anything in the doc) 
> > 
> > Franck 
> > 
> > PS : I got it to work (partially - for petsc, not external packages) on my 
> > laptop (debian). I may (?) push I somebody is interested to have a look (on 
> > going dev ?). 
> > 
> 

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

[Matthew Knepley]

On Sun, Nov 5, 2017 at 8:57 AM, Franck Houssen 
wrote:

> Hello,
>
> Does PETSc provide support for CMake ? I would say this is an on-going
> feature that is not yet fully working, right ?
>
> My understanding is that "./configure" generates the CMakeLists.txt. But
> then, when using cmake, make fails.
> Is this supposed to work yet ? Or is this on-going dev ? (google is
> misleading about that, and, not seen anything in the doc)
>

We supported this a few years ago, but the obscene brokeness of CMake makes
this impossible, so it is no longer supported.

  Thanks,

Matt


> Franck
>
> PS : I got it to work (partially - for petsc, not external packages) on my
> laptop (debian). I may (?) push I somebody is interested to have a look (on
> going dev ?).
>



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

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

[Franck Houssen]

Hello, 

Does PETSc provide support for CMake ? I would say this is an on-going feature 
that is not yet fully working, right ? 

My understanding is that "./configure" generates the CMakeLists.txt. But then, 
when using cmake, make fails. 
Is this supposed to work yet ? Or is this on-going dev ? (google is misleading 
about that, and, not seen anything in the doc) 

Franck 

PS : I got it to work (partially - for petsc, not external packages) on my 
laptop (debian). I may (?) push I somebody is interested to have a look (on 
going dev ?). 

Re: [petsc-dev] CMake

[Jed Brown]

Matthew Knepley knep...@gmail.com writes:

 Now that it is no longer the default build, can we stop it generating
 Makefile in $PETSC_ARCH?

Should we just stop autodetecting the cmake executable?  Users that
want it can use --with-cmake=/usr/bin/cmake.


pgp50uArkwQaa.pgp
Description: PGP signature

Re: [petsc-dev] CMake

[Satish Balay]

On Wed, 18 Dec 2013, Jed Brown wrote:

 Matthew Knepley knep...@gmail.com writes:
 
  Now that it is no longer the default build, can we stop it generating
  Makefile in $PETSC_ARCH?
 
 Should we just stop autodetecting the cmake executable?  Users that
 want it can use --with-cmake=/usr/bin/cmake.

We do need cmake for some externalpackages - so we might have to add
a --with-petsc-buid-with-cmake option or equivalent.

Alternate is to have all cmake files in PETSC_DIR/PETSC_ARCH/cmakebuild [instead
of the current location PETSC_DIR/PETSC_ARCH]

Satish

Re: [petsc-dev] CMake

[Jed Brown]

Satish Balay ba...@mcs.anl.gov writes:
 Alternate is to have all cmake files in PETSC_DIR/PETSC_ARCH/cmakebuild 
 [instead
 of the current location PETSC_DIR/PETSC_ARCH]

I think Matt is annoyed with the presence of Makefile causing noise in
his detector (which is supposed to enforce that PETSc uses only
lowercase makefile), and perhaps with the occasional infinite loops
that CMake goes into from time to time.


pgpBkkICNxZmm.pgp
Description: PGP signature

[petsc-dev] CMake

[Matthew Knepley]

Now that it is no longer the default build, can we stop it generating
Makefile in $PETSC_ARCH?

  Matt

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

[petsc-dev] CMake-assisted CUDA builds ready

[Karl Rupp]

Hi Dave,

thanks for letting me know, I'll merge it to master then.

Best regards,
Karli


On 03/27/2013 04:47 PM, Nystrom, William D wrote:
 I verified that it works for me also.

 Thanks,

 Dave

 
 From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at mcs.anl.gov] on 
 behalf of Jose E. Roman [jroman at dsic.upv.es]
 Sent: Tuesday, March 26, 2013 3:44 PM
 To: For users of the development version of PETSc
 Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready

 El 26/03/2013, a las 21:08, Karl Rupp escribi?:

 Hi again,

 thanks, I think I could eliminate the cause.
 Please give 'next' another try...

 Thanks and best regards,
 Karli

 Yes, it works now. Thanks.

[petsc-dev] CMake-assisted CUDA builds ready

[Nystrom, William D]

I verified that it works for me also.

Thanks,

Dave


From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at mcs.anl.gov] on 
behalf of Jose E. Roman [jro...@dsic.upv.es]
Sent: Tuesday, March 26, 2013 3:44 PM
To: For users of the development version of PETSc
Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready

El 26/03/2013, a las 21:08, Karl Rupp escribi?:

 Hi again,

 thanks, I think I could eliminate the cause.
 Please give 'next' another try...

 Thanks and best regards,
 Karli

Yes, it works now. Thanks.

[petsc-dev] CMake-assisted CUDA builds ready

[Jose E. Roman]

I get errors in the cmake build (in 'next'):

/usr/local/cuda/bin/nvcc 
/home/jroman/soft/petsc/src/mat/impls/aij/mpi/mpicusparse/mpiaijcusparse.cu  
-O -arch=sm_13  --compiler-options , 
-fPIC\,\-Wall\,\-Wwrite-strings\,\-Wno-strict-aliasing\,\-Wno-unknown-pragmas\,\-O\
 \ -m64 -D__INSDIR__= -Dpetsc_EXPORTS -Xcompiler ,\-fPIC\ -DNVCC -M -o 
/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/CMakeFiles/petsc_generated_mpiaijcusparse.cu.o.NVCC-depend
 -I/usr/local/cuda/include -I/home/jroman/soft/petsc/include 
-I/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/include 
-I/usr/local/cuda/include 
-I/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/include/txpetscgpu/include 
-I/home/jroman/soft/cusplibrary -I/home/jroman/soft/cusplibrary/include 
-I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi
nvcc fatal   : Unknown option '-compiler-options ,'
CMake Error at CMakeFiles/petsc_generated_aijcusparse.cu.o.cmake:173 (message):
  Error generating
  
/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/./petsc_generated_aijcusparse.cu.o


I have cmake-2.8 and cuda-4.2.

Configure options: --download-txpetscgpu --with-cuda=1 
--with-cusp-dir=/home/jroman/soft/cusplibrary --with-cusp=1 --with-debugging=0 
--with-thrust=1

I can send the logs to petsc-maint if you want.

Jose

[petsc-dev] CMake-assisted CUDA builds ready

[Karl Rupp]

Hi Jose,

No need to send the logs, I can see the problem: Something is going 
wrong when dealing with double-quotes.
The flag string

  --compiler-options 
,\-fPIC\,\-Wall\,\-Wwrite-strings\,\-Wno-strict-aliasing\,\-Wno-unknown-pragmas\,\-O\

gets passed through BuildSystem, which tries to put double quotes around 
it. This leads to

   --compiler-options 
,-fPIC\,\-Wall\,\-Wwrite-strings\,\-Wno-strict-aliasing\,\-Wno-unknown-pragmas\,\-O\
 
\

instead of

   --compiler-options 
,\-fPIC\,\-Wall\,\-Wwrite-strings\,\-Wno-strict-aliasing\,\-Wno-unknown-pragmas\,\-O\
 


and thus the compiler complains. For some reasons the issue does not 
show up on my machine, even though I have the same versions of CMake and 
CUDA. I'll try to track it down.

Best regards,
Karli


On 03/26/2013 09:40 AM, Jose E. Roman wrote:
 I get errors in the cmake build (in 'next'):

 /usr/local/cuda/bin/nvcc 
 /home/jroman/soft/petsc/src/mat/impls/aij/mpi/mpicusparse/mpiaijcusparse.cu  
 -O -arch=sm_13  --compiler-options , 
 -fPIC\,\-Wall\,\-Wwrite-strings\,\-Wno-strict-aliasing\,\-Wno-unknown-pragmas\,\-O\
  \ -m64 -D__INSDIR__= -Dpetsc_EXPORTS -Xcompiler ,\-fPIC\ -DNVCC -M -o 
 /home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/CMakeFiles/petsc_generated_mpiaijcusparse.cu.o.NVCC-depend
  -I/usr/local/cuda/include -I/home/jroman/soft/petsc/include 
 -I/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/include 
 -I/usr/local/cuda/include 
 -I/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/include/txpetscgpu/include
  -I/home/jroman/soft/cusplibrary -I/home/jroman/soft/cusplibrary/include 
 -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi
 nvcc fatal   : Unknown option '-compiler-options ,'
 CMake Error at CMakeFiles/petsc_generated_aijcusparse.cu.o.cmake:173 
 (message):
Error generating

 /home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/./petsc_generated_aijcusparse.cu.o


 I have cmake-2.8 and cuda-4.2.

 Configure options: --download-txpetscgpu --with-cuda=1 
 --with-cusp-dir=/home/jroman/soft/cusplibrary --with-cusp=1 
 --with-debugging=0 --with-thrust=1

 I can send the logs to petsc-maint if you want.

 Jose

[petsc-dev] CMake-assisted CUDA builds ready

[Karl Rupp]

Hi Jose,

alright, the problem should be fixed in 'next' now. The problem was in 
CMake not consistently interpreting escaped double quotes.

Best regards,
Karli


On 03/26/2013 09:40 AM, Jose E. Roman wrote:
 I get errors in the cmake build (in 'next'):

 /usr/local/cuda/bin/nvcc 
 /home/jroman/soft/petsc/src/mat/impls/aij/mpi/mpicusparse/mpiaijcusparse.cu  
 -O -arch=sm_13  --compiler-options , 
 -fPIC\,\-Wall\,\-Wwrite-strings\,\-Wno-strict-aliasing\,\-Wno-unknown-pragmas\,\-O\
  \ -m64 -D__INSDIR__= -Dpetsc_EXPORTS -Xcompiler ,\-fPIC\ -DNVCC -M -o 
 /home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/CMakeFiles/petsc_generated_mpiaijcusparse.cu.o.NVCC-depend
  -I/usr/local/cuda/include -I/home/jroman/soft/petsc/include 
 -I/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/include 
 -I/usr/local/cuda/include 
 -I/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/include/txpetscgpu/include
  -I/home/jroman/soft/cusplibrary -I/home/jroman/soft/cusplibrary/include 
 -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi
 nvcc fatal   : Unknown option '-compiler-options ,'
 CMake Error at CMakeFiles/petsc_generated_aijcusparse.cu.o.cmake:173 
 (message):
Error generating

 /home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/./petsc_generated_aijcusparse.cu.o


 I have cmake-2.8 and cuda-4.2.

 Configure options: --download-txpetscgpu --with-cuda=1 
 --with-cusp-dir=/home/jroman/soft/cusplibrary --with-cusp=1 
 --with-debugging=0 --with-thrust=1

 I can send the logs to petsc-maint if you want.

 Jose

[petsc-dev] CMake-assisted CUDA builds ready

[Jose E. Roman]

El 26/03/2013, a las 16:19, Karl Rupp escribi?:

 Hi Jose,
 
 alright, the problem should be fixed in 'next' now. The problem was in CMake 
 not consistently interpreting escaped double quotes.
 
 Best regards,
 Karli

Not yet solved:


/usr/local/cuda/bin/nvcc 
/home/jroman/soft/petsc/src/mat/impls/aij/mpi/mpicusp/mpiaijAssemble.cu  -O 
-arch=sm_13  --compiler-options 
,-fPIC,-Wall,-Wwrite-strings,-Wno-strict-aliasing,-Wno-unknown-pragmas,-O -m64 
-D__INSDIR__= -Dpetsc_EXPORTS -Xcompiler ,\-fPIC\ -DNVCC -M -o 
/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/CMakeFiles/petsc_generated_mpiaijAssemble.cu.o.NVCC-depend
 -I/usr/local/cuda/include -I/home/jroman/soft/petsc/include 
-I/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/include 
-I/usr/local/cuda/include 
-I/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/include/txpetscgpu/include 
-I/home/jroman/soft/cusplibrary -I/home/jroman/soft/cusplibrary/include 
-I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi
nvcc fatal   : Unknown option '-compiler-options 
,-fPIC,-Wall,-Wwrite-strings,-Wno-strict-aliasing,-Wno-unknown-pragmas,-O'
CMake Error at CMakeFiles/petsc_generated_mpiaijAssemble.cu.o.cmake:173 
(message):
  Error generating
  
/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/./petsc_generated_mpiaijAssemble.cu.o

[petsc-dev] CMake-assisted CUDA builds ready

[Karl Rupp]

Hi Jose,

which host compiler do you use? nvcc seems to have problems with 
double-quoted flags such as  -O -arch=sm_13 .

Thanks and best regards,
Karli




On 03/26/2013 11:03 AM, Jose E. Roman wrote:

 El 26/03/2013, a las 16:19, Karl Rupp escribi?:

 Hi Jose,

 alright, the problem should be fixed in 'next' now. The problem was in CMake 
 not consistently interpreting escaped double quotes.

 Best regards,
 Karli

 Not yet solved:


 /usr/local/cuda/bin/nvcc 
 /home/jroman/soft/petsc/src/mat/impls/aij/mpi/mpicusp/mpiaijAssemble.cu  -O 
 -arch=sm_13  --compiler-options 
 ,-fPIC,-Wall,-Wwrite-strings,-Wno-strict-aliasing,-Wno-unknown-pragmas,-O 
 -m64 -D__INSDIR__= -Dpetsc_EXPORTS -Xcompiler ,\-fPIC\ -DNVCC -M -o 
 /home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/CMakeFiles/petsc_generated_mpiaijAssemble.cu.o.NVCC-depend
  -I/usr/local/cuda/include -I/home/jroman/soft/petsc/include 
 -I/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/include 
 -I/usr/local/cuda/include 
 -I/home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/include/txpetscgpu/include
  -I/home/jroman/soft/cusplibrary -I/home/jroman/soft/cusplibrary/include 
 -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi
 nvcc fatal   : Unknown option '-compiler-options 
 ,-fPIC,-Wall,-Wwrite-strings,-Wno-strict-aliasing,-Wno-unknown-pragmas,-O'
 CMake Error at CMakeFiles/petsc_generated_mpiaijAssemble.cu.o.cmake:173 
 (message):
Error generating

 /home/jroman/soft/petsc/arch-linux-gnu-c-opt-cuda/./petsc_generated_mpiaijAssemble.cu.o

[petsc-dev] CMake-assisted CUDA builds ready

[Jose E. Roman]

El 26/03/2013, a las 17:27, Karl Rupp escribi?:

 Hi Jose,
 
 which host compiler do you use? nvcc seems to have problems with 
 double-quoted flags such as  -O -arch=sm_13 .
 
 Thanks and best regards,
 Karli


$ nvcc -V
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2012 NVIDIA Corporation
Built on Thu_Apr__5_00:24:31_PDT_2012
Cuda compilation tools, release 4.2, V0.2.1221


$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
4.4.3-4ubuntu5.1' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared 
--enable-multiarch --enable-linker-build-id --with-system-zlib 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc 
--disable-werror --with-arch-32=i486 --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1) 

[petsc-dev] CMake-assisted CUDA builds ready

[Karl Rupp]

Hi again,

thanks, I think I could eliminate the cause.
Please give 'next' another try...

Thanks and best regards,
Karli



On 03/26/2013 11:28 AM, Jose E. Roman wrote:

 El 26/03/2013, a las 17:27, Karl Rupp escribi?:

 Hi Jose,

 which host compiler do you use? nvcc seems to have problems with 
 double-quoted flags such as  -O -arch=sm_13 .

 Thanks and best regards,
 Karli


 $ nvcc -V
 nvcc: NVIDIA (R) Cuda compiler driver
 Copyright (c) 2005-2012 NVIDIA Corporation
 Built on Thu_Apr__5_00:24:31_PDT_2012
 Cuda compilation tools, release 4.2, V0.2.1221


 $ gcc -v
 Using built-in specs.
 Target: x86_64-linux-gnu
 Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
 4.4.3-4ubuntu5.1' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs 
 --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared 
 --enable-multiarch --enable-linker-build-id --with-system-zlib 
 --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
 --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 
 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin 
 --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic 
 --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
 --target=x86_64-linux-gnu
 Thread model: posix
 gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5.1)

[petsc-dev] CMake-assisted CUDA builds ready

[Jose E. Roman]

El 26/03/2013, a las 21:08, Karl Rupp escribi?:

 Hi again,
 
 thanks, I think I could eliminate the cause.
 Please give 'next' another try...
 
 Thanks and best regards,
 Karli

Yes, it works now. Thanks.

[petsc-dev] CMake-assisted CUDA builds ready

[Karl Rupp]

Hi Dave,

it was another timeout issue again. The combination of various external 
packages as well as the optimization flags provided led to a CMake boot 
time of 72 seconds on my machine, which is more than the 60 seconds 
timeout we used so far. The same timeout must have appeared on your machine.

The new timeout is now set to 300 seconds and should also be sufficient 
for weaker machines^1. Waiting in 'next' for another test run :-)

Thanks for all the testing and best regards,
Karli

^1 Except some supercomputers with OpenMP enabled... ;-)


On 03/23/2013 07:48 PM, Dave Nystrom wrote:
 Thanks.  I mistakenly sent the log files to petsc-dev.  Sorry about that.  I
 did a resend and sent them to petsc-maint.

 Dave

 Karl Rupp writes:
Hi Dave,
   
thanks for the log-files and the testing. CMake hangs during it's
startup and thus runs into a timeout. Maybe this is related to the bug
Jed found in CMake 2.8.10.2, I have no other explanation why this hangs.
I'll try to reproduce this as soon as I' at a CUDA-enabled machine again.
   
Best regards,
Karli
   
   
   
On 03/23/2013 06:49 PM, Dave Nystrom wrote:
 Hi Karli,

 Still does not seem to work.  Attached are the logs from the latest 
 attempt.

 Cheers,

 Dave




 Karl Rupp writes:
Hi again,
   
I've found the cause of the issue, namely an overly tight timeout 
 during
the CMake initialization. Dave, could you please rerun reconfigure 
 and
make in the latest `next`?
   
Thanks and best regards,
Karli
   
   
   
On 03/20/2013 07:31 PM, Dave Nystrom wrote:
 Hi Karli,

 Just now seeing this.  I did my build from a clean slate.

 Thanks,

 Dave

 Karl Rupp writes:
Hi Dave,
   
I also found that in some occasions one should issue
$ rm -rf PETSC_ARCH/CMake*
prior to running a reconfigure in order to circumvent a bug 
 [1] in CMake.
   
@Jed, Matt: The current cmakeboot.py removes
PETSC_ARCH/CMakeFiles/{version_string}, which does not seem 
 to even
exist on my machine (CMake 2.8.7). Can we instead just delete 
 the whole
CMakeFiles-folder and probably CMakeCache.txt?
   
Best regards,
Karli
   
[1] http://www.mail-archive.com/cmake at 
 cmake.org/msg44765.html
   
   
   
On 03/20/2013 10:17 AM, Nystrom, William D wrote:
 Hi Karli,

 I ran a test build last night and it failed.  It was a 
 relatively simple configuration where
 I was downloading mpich and cmake and building with 
 threads, cuda and the txpetscgpu
 package.  I was building on a Fedora 17 machine with Cuda 
 5.  The failure seem to be
 associated with cmake.  When I get home this evening, I 
 could send you the configure
 and make logs.  I did not have time this morning before 
 leaving for work.  I wanted to
 give you some early feedback even though the logs will have 
 to wait till this evening.

 Thanks,

 Dave

 --
 Dave Nystrom
 LANL HPC-5
 Phone: 505-667-7913
 Email: wdn at lanl.gov
 Smail: Mail Stop B272
 Group HPC-5
 Los Alamos National Laboratory
 Los Alamos, NM 87545


 
 From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces 
 at mcs.anl.gov] on behalf of Karl Rupp [rupp at mcs.anl.gov]
 Sent: Tuesday, March 19, 2013 4:04 PM
 To: petsc-dev at mcs.anl.gov
 Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready

 Hi Dave,

 perfect, thanks!
 I should add that a reconfigure is needed. It won't work 
 with re-running
 make only.

 Best regards,
 Karli


 On 03/19/2013 04:59 PM, Nystrom, William D wrote:
 Hi Karli,

 I will try this soon and report back when I have results.

 Thanks,

 Dave

 
 From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces 
 at mcs.anl.gov] on behalf of Karl Rupp [rupp at mcs.anl.gov]
 Sent: Tuesday, March 19, 2013 3:58 PM
 To: For users of the development version of PETSc
 Subject: [petsc-dev] CMake-assisted CUDA builds ready

 Dear all,

 I

[petsc-dev] CMake-assisted CUDA builds ready

[Karl Rupp]

Hi Dave,

thanks for the log-files and the testing. CMake hangs during it's 
startup and thus runs into a timeout. Maybe this is related to the bug 
Jed found in CMake 2.8.10.2, I have no other explanation why this hangs. 
I'll try to reproduce this as soon as I' at a CUDA-enabled machine again.

Best regards,
Karli



On 03/23/2013 06:49 PM, Dave Nystrom wrote:
 Hi Karli,

 Still does not seem to work.  Attached are the logs from the latest attempt.

 Cheers,

 Dave




 Karl Rupp writes:
Hi again,
   
I've found the cause of the issue, namely an overly tight timeout during
the CMake initialization. Dave, could you please rerun reconfigure and
make in the latest `next`?
   
Thanks and best regards,
Karli
   
   
   
On 03/20/2013 07:31 PM, Dave Nystrom wrote:
 Hi Karli,

 Just now seeing this.  I did my build from a clean slate.

 Thanks,

 Dave

 Karl Rupp writes:
Hi Dave,
   
I also found that in some occasions one should issue
$ rm -rf PETSC_ARCH/CMake*
prior to running a reconfigure in order to circumvent a bug [1] in 
 CMake.
   
@Jed, Matt: The current cmakeboot.py removes
PETSC_ARCH/CMakeFiles/{version_string}, which does not seem to even
exist on my machine (CMake 2.8.7). Can we instead just delete the 
 whole
CMakeFiles-folder and probably CMakeCache.txt?
   
Best regards,
Karli
   
[1] http://www.mail-archive.com/cmake at cmake.org/msg44765.html
   
   
   
On 03/20/2013 10:17 AM, Nystrom, William D wrote:
 Hi Karli,

 I ran a test build last night and it failed.  It was a relatively 
 simple configuration where
 I was downloading mpich and cmake and building with threads, cuda 
 and the txpetscgpu
 package.  I was building on a Fedora 17 machine with Cuda 5.  The 
 failure seem to be
 associated with cmake.  When I get home this evening, I could 
 send you the configure
 and make logs.  I did not have time this morning before leaving 
 for work.  I wanted to
 give you some early feedback even though the logs will have to 
 wait till this evening.

 Thanks,

 Dave

 --
 Dave Nystrom
 LANL HPC-5
 Phone: 505-667-7913
 Email: wdn at lanl.gov
 Smail: Mail Stop B272
 Group HPC-5
 Los Alamos National Laboratory
 Los Alamos, NM 87545


 
 From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at 
 mcs.anl.gov] on behalf of Karl Rupp [rupp at mcs.anl.gov]
 Sent: Tuesday, March 19, 2013 4:04 PM
 To: petsc-dev at mcs.anl.gov
 Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready

 Hi Dave,

 perfect, thanks!
 I should add that a reconfigure is needed. It won't work with 
 re-running
 make only.

 Best regards,
 Karli


 On 03/19/2013 04:59 PM, Nystrom, William D wrote:
 Hi Karli,

 I will try this soon and report back when I have results.

 Thanks,

 Dave

 
 From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at 
 mcs.anl.gov] on behalf of Karl Rupp [rupp at mcs.anl.gov]
 Sent: Tuesday, March 19, 2013 3:58 PM
 To: For users of the development version of PETSc
 Subject: [petsc-dev] CMake-assisted CUDA builds ready

 Dear all,

 I just merged the CMake-based builds for CUDA-packages into 
 'next',
 reducing compilation times considerably compared to the old 
 legacy
 builds. While the legacy builds print something like
 'libfast in DIR'
 the new CMake-based builds print the usual percentage counters 
 in front.

 Any feedback on the proper functionality (both positive and 
 negative)
 are appreciated.

 Thanks and best regards,
 Karli


   

[petsc-dev] CMake-assisted CUDA builds ready

[Dave Nystrom]

Thanks.  I mistakenly sent the log files to petsc-dev.  Sorry about that.  I
did a resend and sent them to petsc-maint.

Dave

Karl Rupp writes:
  Hi Dave,
  
  thanks for the log-files and the testing. CMake hangs during it's 
  startup and thus runs into a timeout. Maybe this is related to the bug 
  Jed found in CMake 2.8.10.2, I have no other explanation why this hangs. 
  I'll try to reproduce this as soon as I' at a CUDA-enabled machine again.
  
  Best regards,
  Karli
  
  
  
  On 03/23/2013 06:49 PM, Dave Nystrom wrote:
   Hi Karli,
  
   Still does not seem to work.  Attached are the logs from the latest 
   attempt.
  
   Cheers,
  
   Dave
  
  
  
  
   Karl Rupp writes:
  Hi again,
 
  I've found the cause of the issue, namely an overly tight timeout 
   during
  the CMake initialization. Dave, could you please rerun reconfigure and
  make in the latest `next`?
 
  Thanks and best regards,
  Karli
 
 
 
  On 03/20/2013 07:31 PM, Dave Nystrom wrote:
   Hi Karli,
  
   Just now seeing this.  I did my build from a clean slate.
  
   Thanks,
  
   Dave
  
   Karl Rupp writes:
  Hi Dave,
 
  I also found that in some occasions one should issue
  $ rm -rf PETSC_ARCH/CMake*
  prior to running a reconfigure in order to circumvent a bug [1] 
   in CMake.
 
  @Jed, Matt: The current cmakeboot.py removes
  PETSC_ARCH/CMakeFiles/{version_string}, which does not seem to 
   even
  exist on my machine (CMake 2.8.7). Can we instead just delete 
   the whole
  CMakeFiles-folder and probably CMakeCache.txt?
 
  Best regards,
  Karli
 
  [1] http://www.mail-archive.com/cmake at cmake.org/msg44765.html
 
 
 
  On 03/20/2013 10:17 AM, Nystrom, William D wrote:
   Hi Karli,
  
   I ran a test build last night and it failed.  It was a 
   relatively simple configuration where
   I was downloading mpich and cmake and building with threads, 
   cuda and the txpetscgpu
   package.  I was building on a Fedora 17 machine with Cuda 5.  
   The failure seem to be
   associated with cmake.  When I get home this evening, I could 
   send you the configure
   and make logs.  I did not have time this morning before 
   leaving for work.  I wanted to
   give you some early feedback even though the logs will have to 
   wait till this evening.
  
   Thanks,
  
   Dave
  
   --
   Dave Nystrom
   LANL HPC-5
   Phone: 505-667-7913
   Email: wdn at lanl.gov
   Smail: Mail Stop B272
   Group HPC-5
   Los Alamos National Laboratory
   Los Alamos, NM 87545
  
  
   
   From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at 
   mcs.anl.gov] on behalf of Karl Rupp [rupp at mcs.anl.gov]
   Sent: Tuesday, March 19, 2013 4:04 PM
   To: petsc-dev at mcs.anl.gov
   Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready
  
   Hi Dave,
  
   perfect, thanks!
   I should add that a reconfigure is needed. It won't work with 
   re-running
   make only.
  
   Best regards,
   Karli
  
  
   On 03/19/2013 04:59 PM, Nystrom, William D wrote:
   Hi Karli,
  
   I will try this soon and report back when I have results.
  
   Thanks,
  
   Dave
  
   
   From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at 
   mcs.anl.gov] on behalf of Karl Rupp [rupp at mcs.anl.gov]
   Sent: Tuesday, March 19, 2013 3:58 PM
   To: For users of the development version of PETSc
   Subject: [petsc-dev] CMake-assisted CUDA builds ready
  
   Dear all,
  
   I just merged the CMake-based builds for CUDA-packages into 
   'next',
   reducing compilation times considerably compared to the old 
   legacy
   builds. While the legacy builds print something like
   'libfast in DIR'
   the new CMake-based builds print the usual percentage 
   counters in front.
  
   Any feedback on the proper functionality (both positive and 
   negative)
   are appreciated.
  
   Thanks and best regards,
   Karli
  
  
 
  
  
  

[petsc-dev] CMake-assisted CUDA builds ready

[Karl Rupp]

Hi again,

I've found the cause of the issue, namely an overly tight timeout during 
the CMake initialization. Dave, could you please rerun reconfigure and 
make in the latest `next`?

Thanks and best regards,
Karli



On 03/20/2013 07:31 PM, Dave Nystrom wrote:
 Hi Karli,

 Just now seeing this.  I did my build from a clean slate.

 Thanks,

 Dave

 Karl Rupp writes:
Hi Dave,
   
I also found that in some occasions one should issue
$ rm -rf PETSC_ARCH/CMake*
prior to running a reconfigure in order to circumvent a bug [1] in CMake.
   
@Jed, Matt: The current cmakeboot.py removes
PETSC_ARCH/CMakeFiles/{version_string}, which does not seem to even
exist on my machine (CMake 2.8.7). Can we instead just delete the whole
CMakeFiles-folder and probably CMakeCache.txt?
   
Best regards,
Karli
   
[1] http://www.mail-archive.com/cmake at cmake.org/msg44765.html
   
   
   
On 03/20/2013 10:17 AM, Nystrom, William D wrote:
 Hi Karli,

 I ran a test build last night and it failed.  It was a relatively 
 simple configuration where
 I was downloading mpich and cmake and building with threads, cuda and 
 the txpetscgpu
 package.  I was building on a Fedora 17 machine with Cuda 5.  The 
 failure seem to be
 associated with cmake.  When I get home this evening, I could send you 
 the configure
 and make logs.  I did not have time this morning before leaving for 
 work.  I wanted to
 give you some early feedback even though the logs will have to wait 
 till this evening.

 Thanks,

 Dave

 --
 Dave Nystrom
 LANL HPC-5
 Phone: 505-667-7913
 Email: wdn at lanl.gov
 Smail: Mail Stop B272
 Group HPC-5
 Los Alamos National Laboratory
 Los Alamos, NM 87545


 
 From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at 
 mcs.anl.gov] on behalf of Karl Rupp [rupp at mcs.anl.gov]
 Sent: Tuesday, March 19, 2013 4:04 PM
 To: petsc-dev at mcs.anl.gov
 Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready

 Hi Dave,

 perfect, thanks!
 I should add that a reconfigure is needed. It won't work with re-running
 make only.

 Best regards,
 Karli


 On 03/19/2013 04:59 PM, Nystrom, William D wrote:
 Hi Karli,

 I will try this soon and report back when I have results.

 Thanks,

 Dave

 
 From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at 
 mcs.anl.gov] on behalf of Karl Rupp [rupp at mcs.anl.gov]
 Sent: Tuesday, March 19, 2013 3:58 PM
 To: For users of the development version of PETSc
 Subject: [petsc-dev] CMake-assisted CUDA builds ready

 Dear all,

 I just merged the CMake-based builds for CUDA-packages into 'next',
 reducing compilation times considerably compared to the old legacy
 builds. While the legacy builds print something like
 'libfast in DIR'
 the new CMake-based builds print the usual percentage counters in 
 front.

 Any feedback on the proper functionality (both positive and negative)
 are appreciated.

 Thanks and best regards,
 Karli


   

[petsc-dev] CMake-assisted CUDA builds ready

[Nystrom, William D]

Hi Karli,

I ran a test build last night and it failed.  It was a relatively simple 
configuration where
I was downloading mpich and cmake and building with threads, cuda and the 
txpetscgpu
package.  I was building on a Fedora 17 machine with Cuda 5.  The failure seem 
to be
associated with cmake.  When I get home this evening, I could send you the 
configure
and make logs.  I did not have time this morning before leaving for work.  I 
wanted to
give you some early feedback even though the logs will have to wait till this 
evening.

Thanks,

Dave

--
Dave Nystrom
LANL HPC-5
Phone: 505-667-7913
Email: wdn at lanl.gov
Smail: Mail Stop B272
   Group HPC-5
   Los Alamos National Laboratory
   Los Alamos, NM 87545



From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at mcs.anl.gov] on 
behalf of Karl Rupp [r...@mcs.anl.gov]
Sent: Tuesday, March 19, 2013 4:04 PM
To: petsc-dev at mcs.anl.gov
Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready

Hi Dave,

perfect, thanks!
I should add that a reconfigure is needed. It won't work with re-running
make only.

Best regards,
Karli


On 03/19/2013 04:59 PM, Nystrom, William D wrote:
 Hi Karli,

 I will try this soon and report back when I have results.

 Thanks,

 Dave

 
 From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at mcs.anl.gov] on 
 behalf of Karl Rupp [rupp at mcs.anl.gov]
 Sent: Tuesday, March 19, 2013 3:58 PM
 To: For users of the development version of PETSc
 Subject: [petsc-dev] CMake-assisted CUDA builds ready

 Dear all,

 I just merged the CMake-based builds for CUDA-packages into 'next',
 reducing compilation times considerably compared to the old legacy
 builds. While the legacy builds print something like
'libfast in DIR'
 the new CMake-based builds print the usual percentage counters in front.

 Any feedback on the proper functionality (both positive and negative)
 are appreciated.

 Thanks and best regards,
 Karli

[petsc-dev] CMake-assisted CUDA builds ready

[Karl Rupp]

Hi Dave,

thanks for the first piece of feedback. I'll wait for the logs in order 
to get an idea whether BuildSystem, FindCUDA.cmake, or any other 
component is causing the troubles.

Best regards,
Karli


On 03/20/2013 10:17 AM, Nystrom, William D wrote:
 Hi Karli,

 I ran a test build last night and it failed.  It was a relatively simple 
 configuration where
 I was downloading mpich and cmake and building with threads, cuda and the 
 txpetscgpu
 package.  I was building on a Fedora 17 machine with Cuda 5.  The failure 
 seem to be
 associated with cmake.  When I get home this evening, I could send you the 
 configure
 and make logs.  I did not have time this morning before leaving for work.  I 
 wanted to
 give you some early feedback even though the logs will have to wait till this 
 evening.

 Thanks,

 Dave

 --
 Dave Nystrom
 LANL HPC-5
 Phone: 505-667-7913
 Email: wdn at lanl.gov
 Smail: Mail Stop B272
 Group HPC-5
 Los Alamos National Laboratory
 Los Alamos, NM 87545


 
 From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at mcs.anl.gov] on 
 behalf of Karl Rupp [rupp at mcs.anl.gov]
 Sent: Tuesday, March 19, 2013 4:04 PM
 To: petsc-dev at mcs.anl.gov
 Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready

 Hi Dave,

 perfect, thanks!
 I should add that a reconfigure is needed. It won't work with re-running
 make only.

 Best regards,
 Karli


 On 03/19/2013 04:59 PM, Nystrom, William D wrote:
 Hi Karli,

 I will try this soon and report back when I have results.

 Thanks,

 Dave

 
 From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at mcs.anl.gov] on 
 behalf of Karl Rupp [rupp at mcs.anl.gov]
 Sent: Tuesday, March 19, 2013 3:58 PM
 To: For users of the development version of PETSc
 Subject: [petsc-dev] CMake-assisted CUDA builds ready

 Dear all,

 I just merged the CMake-based builds for CUDA-packages into 'next',
 reducing compilation times considerably compared to the old legacy
 builds. While the legacy builds print something like
 'libfast in DIR'
 the new CMake-based builds print the usual percentage counters in front.

 Any feedback on the proper functionality (both positive and negative)
 are appreciated.

 Thanks and best regards,
 Karli

[petsc-dev] CMake-assisted CUDA builds ready

[Karl Rupp]

Hi Dave,

I also found that in some occasions one should issue
$ rm -rf PETSC_ARCH/CMake*
prior to running a reconfigure in order to circumvent a bug [1] in CMake.

@Jed, Matt: The current cmakeboot.py removes 
PETSC_ARCH/CMakeFiles/{version_string}, which does not seem to even 
exist on my machine (CMake 2.8.7). Can we instead just delete the whole 
CMakeFiles-folder and probably CMakeCache.txt?

Best regards,
Karli

[1] http://www.mail-archive.com/cmake at cmake.org/msg44765.html



On 03/20/2013 10:17 AM, Nystrom, William D wrote:
 Hi Karli,

 I ran a test build last night and it failed.  It was a relatively simple 
 configuration where
 I was downloading mpich and cmake and building with threads, cuda and the 
 txpetscgpu
 package.  I was building on a Fedora 17 machine with Cuda 5.  The failure 
 seem to be
 associated with cmake.  When I get home this evening, I could send you the 
 configure
 and make logs.  I did not have time this morning before leaving for work.  I 
 wanted to
 give you some early feedback even though the logs will have to wait till this 
 evening.

 Thanks,

 Dave

 --
 Dave Nystrom
 LANL HPC-5
 Phone: 505-667-7913
 Email: wdn at lanl.gov
 Smail: Mail Stop B272
 Group HPC-5
 Los Alamos National Laboratory
 Los Alamos, NM 87545


 
 From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at mcs.anl.gov] on 
 behalf of Karl Rupp [rupp at mcs.anl.gov]
 Sent: Tuesday, March 19, 2013 4:04 PM
 To: petsc-dev at mcs.anl.gov
 Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready

 Hi Dave,

 perfect, thanks!
 I should add that a reconfigure is needed. It won't work with re-running
 make only.

 Best regards,
 Karli


 On 03/19/2013 04:59 PM, Nystrom, William D wrote:
 Hi Karli,

 I will try this soon and report back when I have results.

 Thanks,

 Dave

 
 From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at mcs.anl.gov] on 
 behalf of Karl Rupp [rupp at mcs.anl.gov]
 Sent: Tuesday, March 19, 2013 3:58 PM
 To: For users of the development version of PETSc
 Subject: [petsc-dev] CMake-assisted CUDA builds ready

 Dear all,

 I just merged the CMake-based builds for CUDA-packages into 'next',
 reducing compilation times considerably compared to the old legacy
 builds. While the legacy builds print something like
 'libfast in DIR'
 the new CMake-based builds print the usual percentage counters in front.

 Any feedback on the proper functionality (both positive and negative)
 are appreciated.

 Thanks and best regards,
 Karli

[petsc-dev] CMake-assisted CUDA builds ready

[Jed Brown]

On Wed, Mar 20, 2013 at 2:03 PM, Karl Rupp rupp at mcs.anl.gov wrote:

 I also found that in some occasions one should issue
 gt; rm -rf PETSC_ARCH/CMake*
 prior to running a reconfigure in order to circumvent a bug [1] in CMake.

 @Jed, Matt: The current cmakeboot.py removes 
 PETSC_ARCH/CMakeFiles/{**version_string},
 which does not seem to even exist on my machine (CMake 2.8.7). Can we
 instead just delete the whole CMakeFiles-folder and probably CMakeCache.txt?


AFAIK, the bug did not exist in earlier versions of CMake. I don't want to
delete all of CMakeFiles because it implies that _everything_ would have to
be recompiled after re-running cmakeboot.py.

Did you encounter another bug or just the one cited?

BTW, what sort of project introduces an infinite-loop bug in a subminor
release and then is incredulous that you would expect to be able to run the
tool more than once?
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130320/61d1dcce/attachment.html

[petsc-dev] CMake-assisted CUDA builds ready

[Karl Rupp]

Hi Jed,

On 03/20/2013 02:09 PM, Jed Brown wrote:

 On Wed, Mar 20, 2013 at 2:03 PM, Karl Rupp rupp at mcs.anl.gov
 mailto:rupp at mcs.anl.gov wrote:

 I also found that in some occasions one should issue
  gt; rm -rf PETSC_ARCH/CMake*
 prior to running a reconfigure in order to circumvent a bug [1] in
 CMake.

 @Jed, Matt: The current cmakeboot.py removes
 PETSC_ARCH/CMakeFiles/{__version_string}, which does not seem to
 even exist on my machine (CMake 2.8.7). Can we instead just delete
 the whole CMakeFiles-folder and probably CMakeCache.txt?


 AFAIK, the bug did not exist in earlier versions of CMake. I don't want
 to delete all of CMakeFiles because it implies that _everything_ would
 have to be recompiled after re-running cmakeboot.py.

Yes, I know that this is a heavy operation. On the other hand, it only 
occurs after a reconfigure, so it's not supposed to happen too often. 
Anyway, with CUDA enabled I can deterministically reproduce the error in 
`next`:
  $ rm -rf PETSC_ARCH/CMake*
  $ PETSC_ARCH/conf/reconfigure-xxx.py # Fine, generates CMake build
  $ PETSC_ARCH/conf/reconfigure-xxx.py # Fine, generates CMake build
  $ make ... all   # compiles
  $ PETSC_ARCH/conf/reconfigure-xxx.py # Hangs, legacy fallback

However, the problem does not show up without CUDA.

 Did you encounter another bug or just the one cited?

I don't know yet what precisely is causing the problem. It may also be 
due to FindCUDA.cmake.

 BTW, what sort of project introduces an infinite-loop bug in a subminor
 release and then is incredulous that you would expect to be able to run
 the tool more than once?

How dare you actually try to really *use* the tool? ;-)

Best regards,
Karli

[petsc-dev] CMake-assisted CUDA builds ready

[Jed Brown]

On Wed, Mar 20, 2013 at 3:19 PM, Karl Rupp rupp at mcs.anl.gov wrote:

 Yes, I know that this is a heavy operation. On the other hand, it only
 occurs after a reconfigure, so it's not supposed to happen too often.
 Anyway, with CUDA enabled I can deterministically reproduce the error in
 `next`:
  gt; rm -rf PETSC_ARCH/CMake*
  gt; PETSC_ARCH/conf/reconfigure-**xxx.py # Fine, generates CMake
 build
  gt; PETSC_ARCH/conf/reconfigure-**xxx.py # Fine, generates CMake
 build
  gt; make ... all   # compiles
  gt; PETSC_ARCH/conf/reconfigure-**xxx.py # Hangs, legacy fallback

 However, the problem does not show up without CUDA.


It would be friendly to track down the actual problem and report it as a
bug for them to save in their tracker and close when there has been no
action for years (and why is an infinite loop a problem anyway). ;-)

I guess I would add this CUDA work-around to cmakeboot.py.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130320/0c17b273/attachment.html

[petsc-dev] CMake-assisted CUDA builds ready

[Dave Nystrom]

Hi Karli,

Just now seeing this.  I did my build from a clean slate.

Thanks,

Dave

Karl Rupp writes:
  Hi Dave,
  
  I also found that in some occasions one should issue
  $ rm -rf PETSC_ARCH/CMake*
  prior to running a reconfigure in order to circumvent a bug [1] in CMake.
  
  @Jed, Matt: The current cmakeboot.py removes 
  PETSC_ARCH/CMakeFiles/{version_string}, which does not seem to even 
  exist on my machine (CMake 2.8.7). Can we instead just delete the whole 
  CMakeFiles-folder and probably CMakeCache.txt?
  
  Best regards,
  Karli
  
  [1] http://www.mail-archive.com/cmake at cmake.org/msg44765.html
  
  
  
  On 03/20/2013 10:17 AM, Nystrom, William D wrote:
   Hi Karli,
  
   I ran a test build last night and it failed.  It was a relatively simple 
   configuration where
   I was downloading mpich and cmake and building with threads, cuda and the 
   txpetscgpu
   package.  I was building on a Fedora 17 machine with Cuda 5.  The failure 
   seem to be
   associated with cmake.  When I get home this evening, I could send you the 
   configure
   and make logs.  I did not have time this morning before leaving for work.  
   I wanted to
   give you some early feedback even though the logs will have to wait till 
   this evening.
  
   Thanks,
  
   Dave
  
   --
   Dave Nystrom
   LANL HPC-5
   Phone: 505-667-7913
   Email: wdn at lanl.gov
   Smail: Mail Stop B272
   Group HPC-5
   Los Alamos National Laboratory
   Los Alamos, NM 87545
  
  
   
   From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at mcs.anl.gov] 
   on behalf of Karl Rupp [rupp at mcs.anl.gov]
   Sent: Tuesday, March 19, 2013 4:04 PM
   To: petsc-dev at mcs.anl.gov
   Subject: Re: [petsc-dev] CMake-assisted CUDA builds ready
  
   Hi Dave,
  
   perfect, thanks!
   I should add that a reconfigure is needed. It won't work with re-running
   make only.
  
   Best regards,
   Karli
  
  
   On 03/19/2013 04:59 PM, Nystrom, William D wrote:
   Hi Karli,
  
   I will try this soon and report back when I have results.
  
   Thanks,
  
   Dave
  
   
   From: petsc-dev-bounces at mcs.anl.gov [petsc-dev-bounces at mcs.anl.gov] 
   on behalf of Karl Rupp [rupp at mcs.anl.gov]
   Sent: Tuesday, March 19, 2013 3:58 PM
   To: For users of the development version of PETSc
   Subject: [petsc-dev] CMake-assisted CUDA builds ready
  
   Dear all,
  
   I just merged the CMake-based builds for CUDA-packages into 'next',
   reducing compilation times considerably compared to the old legacy
   builds. While the legacy builds print something like
   'libfast in DIR'
   the new CMake-based builds print the usual percentage counters in front.
  
   Any feedback on the proper functionality (both positive and negative)
   are appreciated.
  
   Thanks and best regards,
   Karli
  
  
  

[petsc-dev] cmake 2.8-10.1 failing on my mac

[Barry Smith]

   I upgraded cmake on my mac and now configure hangs will running cmake. If I 
kill the cmake process I see the following in configure.log

When I use --download-cmake and it gets the old version then that runs 
fine. Has PETSc's cmake stuff been tested with 2.8-10.1?

   Barry

Pushing language C
Popping language C
sh: ['/usr/bin/cmake', '--version']
Executing: ['/usr/bin/cmake', '--version']
sh: cmake version 2.8.10.1

Pushing language C
Popping language C
Invoking: ['/usr/bin/cmake', '--trace', '--debug-output', 
'/Users/barrysmith/Src/petsc-dev', '-DCMAKE_C_COMPILER:FILEPATH=gcc', 
'-DCMAKE_C_FLAGS:STRING= -Wall -Wwrite-strings -Wno-strict-aliasing 
-Wno-unknown-pragmas -g3 -fno-inline -O0', '-DCMAKE_AR=/usr/bin/ar', 
'-DCMAKE_RANLIB=/usr/bin/ranlib']
sh: ['/usr/bin/cmake', '--trace', '--debug-output', 
'/Users/barrysmith/Src/petsc-dev', '-DCMAKE_C_COMPILER:FILEPATH=gcc', 
'-DCMAKE_C_FLAGS:STRING= -Wall -Wwrite-strings -Wno-strict-aliasing 
-Wno-unknown-pragmas -g3 -fno-inline -O0', '-DCMAKE_AR=/usr/bin/ar', 
'-DCMAKE_RANLIB=/usr/bin/ranlib']
Executing: ['/usr/bin/cmake', '--trace', '--debug-output', 
'/Users/barrysmith/Src/petsc-dev', '-DCMAKE_C_COMPILER:FILEPATH=gcc', 
'-DCMAKE_C_FLAGS:STRING= -Wall -Wwrite-strings -Wno-strict-aliasing 
-Wno-unknown-pragmas -g3 -fno-inline -O0', '-DCMAKE_AR=/usr/bin/ar', 
'-DCMAKE_RANLIB=/usr/bin/ranlib']
sh: Running with trace output on.
Running with debug output on.
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done
-- Configuring done

  
===
  CMake setup incomplete (status 9), falling back to legacy 
build
  
===

Could not read file /Users/barrysmith/Src/petsc-dev/arch-test/CMakeCache.txt: 
IOError(2, 'No such file or directory')
  CMake configuration was unsuccessful

[petsc-dev] cmake 2.8-10.1 failing on my mac

[Barry Smith]

   Yup this also works on Mountain lion with the latest Xcode. Must be 
something about the .dmg Mac specific Application build that fucks it up.

No worries, I've just backed out to using the the older version for my work.

BTW: whoever added support for --download-xxx=http:   thanks!


   Barry

On Nov 7, 2012, at 10:32 PM, Satish Balay balay at mcs.anl.gov wrote:

 I attempted 
 --download-cmake=http://www.cmake.org/files/v2.8/cmake-2.8.10.1.tar.gz on 
 linux and osx 10.6 and
 that went through fine..
 
 Could not read file 
 /Users/barrysmith/Src/petsc-dev/arch-test/CMakeCache.txt: IOError(2, 'No 
 such file or directory')
 
 I'm not sure what this means. Jed might have ideas.
 
 Satish
 
 On Wed, 7 Nov 2012, Barry Smith wrote:
 
 
 
   I upgraded cmake on my mac and now configure hangs will running cmake. If 
 I kill the cmake process I see the following in configure.log
 
When I use --download-cmake and it gets the old version then that runs 
 fine. Has PETSc's cmake stuff been tested with 2.8-10.1?
 
   Barry
 
Pushing language C
Popping language C
 sh: ['/usr/bin/cmake', '--version']
 Executing: ['/usr/bin/cmake', '--version']
 sh: cmake version 2.8.10.1
 
Pushing language C
Popping language C
 Invoking: ['/usr/bin/cmake', '--trace', '--debug-output', 
 '/Users/barrysmith/Src/petsc-dev', '-DCMAKE_C_COMPILER:FILEPATH=gcc', 
 '-DCMAKE_C_FLAGS:STRING= -Wall -Wwrite-strings -Wno-strict-aliasing 
 -Wno-unknown-pragmas -g3 -fno-inline -O0', '-DCMAKE_AR=/usr/bin/ar', 
 '-DCMAKE_RANLIB=/usr/bin/ranlib']
 sh: ['/usr/bin/cmake', '--trace', '--debug-output', 
 '/Users/barrysmith/Src/petsc-dev', '-DCMAKE_C_COMPILER:FILEPATH=gcc', 
 '-DCMAKE_C_FLAGS:STRING= -Wall -Wwrite-strings -Wno-strict-aliasing 
 -Wno-unknown-pragmas -g3 -fno-inline -O0', '-DCMAKE_AR=/usr/bin/ar', 
 '-DCMAKE_RANLIB=/usr/bin/ranlib']
 Executing: ['/usr/bin/cmake', '--trace', '--debug-output', 
 '/Users/barrysmith/Src/petsc-dev', '-DCMAKE_C_COMPILER:FILEPATH=gcc', 
 '-DCMAKE_C_FLAGS:STRING= -Wall -Wwrite-strings -Wno-strict-aliasing 
 -Wno-unknown-pragmas -g3 -fno-inline -O0', '-DCMAKE_AR=/usr/bin/ar', 
 '-DCMAKE_RANLIB=/usr/bin/ranlib']
 sh: Running with trace output on.
 Running with debug output on.
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 -- Configuring done
 
  
 ===
  CMake setup incomplete (status 9), falling back to legacy 
 build
  
 ===
 
 Could not read file 
 /Users/barrysmith/Src/petsc-dev/arch-test/CMakeCache.txt: IOError(2, 'No 
 such file or directory')
  CMake configuration was unsuccessful
 
 
 
 
 

[petsc-dev] cmake 2.8-10.1 failing on my mac

[Jed Brown]

On Wed, Nov 7, 2012 at 10:32 PM, Satish Balay balay at mcs.anl.gov wrote:

  Could not read file
 /Users/barrysmith/Src/petsc-dev/arch-test/CMakeCache.txt: IOError(2, 'No
 such file or directory')

 I'm not sure what this means. Jed might have ideas.


It means you have to wipe the disk and install a real operating system.
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20121107/da7d132c/attachment.html

[petsc-dev] CMake version

[Alexander Grayver]

Hi dev-team,

Yesterday I duilt petsc-dev successfully, today I updated it and tried 
to reconfigure:

---
CMake  2.8.5 is needed to build METIS
***

lib/petsc-dev cmake
cmake version 2.8.4

Just tell me, something has been changed in petsc or it's rather my machine?

Regards,
Alexander

[petsc-dev] CMake version

[Alexander Grayver]

I installed cmake 2.8.6 in my local directory and petsc sees it there, 
but still gives same error:

 Defined make macro CMAKE  to /home/bin/cmake/bin/cmake
 Pushing language C

TEST configureLibrary from 
PETSc.packages.metis(/home/lib/petsc-dev/config/BuildSystem/config/package.py:417)
TESTING: configureLibrary from 
PETSc.packages.metis(config/BuildSystem/config/package.py:417)
   Find an installation and check if it can work with PETSc
==
   Checking for a functional metis
   Looking for METIS in directory starting with metis
   Found a copy of METIS in metis-5.0.2
***
  UNABLE to CONFIGURE with GIVEN OPTIONS(see configure.log 
for details):
---
CMake  2.8.5 is needed to build METIS
***
   File /home/lib/petsc-dev/config/configure.py, line 287, in 
petsc_configure
 framework.configure(out = sys.stdout)
   File /home/lib/petsc-dev/config/BuildSystem/config/framework.py, 
line 929, in configure
 child.configure()
   File /home/lib/petsc-dev/config/BuildSystem/config/package.py, line 
506, in configure
 self.executeTest(self.configureLibrary)
   File /home/lib/petsc-dev/config/BuildSystem/config/base.py, line 
115, in executeTest
 ret = apply(test, args,kargs)
   File /home/lib/petsc-dev/config/BuildSystem/config/package.py, line 
433, in configureLibrary
 for location, directory, lib, incl in self.generateGuesses():
   File /home/lib/petsc-dev/config/BuildSystem/config/package.py, line 
228, in generateGuesses
 d = self.checkDownload(1)
   File /home/lib/petsc-dev/config/BuildSystem/config/package.py, line 
313, in checkDownload
 return self.getInstallDir()
   File /home/lib/petsc-dev/config/BuildSystem/config/package.py, line 
183, in getInstallDir
 return os.path.abspath(self.Install())
   File /home/lib/petsc-dev/config/PETSc/packages/metis.py, line 30, 
in Install
 raise RuntimeError('CMake  2.8.5 is needed to build METIS')

lib/petsc-dev cmake -version
cmake version 2.8.6


On 09.12.2011 09:56, Alexander Grayver wrote:
 Hi dev-team,

 Yesterday I duilt petsc-dev successfully, today I updated it and tried 
 to reconfigure:

 ---
  

 CMake  2.8.5 is needed to build METIS
 ***
  


 lib/petsc-dev cmake
 cmake version 2.8.4

 Just tell me, something has been changed in petsc or it's rather my 
 machine?

 Regards,
 Alexander

[petsc-dev] CMake version

[Alexander Grayver]

Thanks Satish!
Works well.

On 09.12.2011 16:12, Satish Balay wrote:
 pushed a fix for this issue.

 Satish

 On Fri, 9 Dec 2011, Satish Balay wrote:

 for now you should be able to use --download-cmake. Will check why the
 cmake from PATH is not working..

 Satish

 On Fri, 9 Dec 2011, Alexander Grayver wrote:

 I installed cmake 2.8.6 in my local directory and petsc sees it there, but
 still gives same error:

  Defined make macro CMAKE  to /home/bin/cmake/bin/cmake
  Pushing language C
 
 TEST configureLibrary from
 PETSc.packages.metis(/home/lib/petsc-dev/config/BuildSystem/config/package.py:417)
 TESTING: configureLibrary from
 PETSc.packages.metis(config/BuildSystem/config/package.py:417)
Find an installation and check if it can work with PETSc
 ==
Checking for a functional metis
Looking for METIS in directory starting with metis
Found a copy of METIS in metis-5.0.2
 ***
   UNABLE to CONFIGURE with GIVEN OPTIONS(see configure.log for
 details):
 ---
 CMake  2.8.5 is needed to build METIS
 ***
File /home/lib/petsc-dev/config/configure.py, line 287, in 
 petsc_configure
  framework.configure(out = sys.stdout)
File /home/lib/petsc-dev/config/BuildSystem/config/framework.py, line 
 929,
 in configure
  child.configure()
File /home/lib/petsc-dev/config/BuildSystem/config/package.py, line 
 506,
 in configure
  self.executeTest(self.configureLibrary)
File /home/lib/petsc-dev/config/BuildSystem/config/base.py, line 115, 
 in
 executeTest
  ret = apply(test, args,kargs)
File /home/lib/petsc-dev/config/BuildSystem/config/package.py, line 
 433,
 in configureLibrary
  for location, directory, lib, incl in self.generateGuesses():
File /home/lib/petsc-dev/config/BuildSystem/config/package.py, line 
 228,
 in generateGuesses
  d = self.checkDownload(1)
File /home/lib/petsc-dev/config/BuildSystem/config/package.py, line 
 313,
 in checkDownload
  return self.getInstallDir()
File /home/lib/petsc-dev/config/BuildSystem/config/package.py, line 
 183,
 in getInstallDir
  return os.path.abspath(self.Install())
File /home/lib/petsc-dev/config/PETSc/packages/metis.py, line 30, in
 Install
  raise RuntimeError('CMake  2.8.5 is needed to build METIS')

 lib/petsc-dev  cmake -version
 cmake version 2.8.6


 On 09.12.2011 09:56, Alexander Grayver wrote:
 Hi dev-team,

 Yesterday I duilt petsc-dev successfully, today I updated it and tried to
 reconfigure:


 ---
 CMake  2.8.5 is needed to build METIS
 ***

 lib/petsc-dev  cmake
 cmake version 2.8.4

 Just tell me, something has been changed in petsc or it's rather my 
 machine?

 Regards,
 Alexander

[petsc-dev] cmake problem

[Barry Smith]

  Jed,

  Please see the error below. What is the approved way to recover from 
something incomprehensible to me like this? Shouldn't a reconfigure clean up 
all possible dangers?

Thanks

   Barry



barry-smiths-macbook-pro:petsc-dev barrysmith$ 
./arch-gnu/conf/reconfigure-arch-gnu.py
===
 Configuring PETSc to compile on your system   
===
TESTING: alternateConfigureLibrary from 
PETSc.packages.mpi4py(config/PETSc/packages/mpi4py.py:49)   
Compilers:
  C Compiler: /Users/barrysmith/Src/petsc-dev/arch-gnu/bin/mpicc  -Wall 
-Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 
  CUDA Compiler:  nvcc  -g 
  Fortran Compiler:   /Users/barrysmith/Src/petsc-dev/arch-gnu/bin/mpif90   
-Wall -Wno-unused-variable -Wno-unused-dummy-argument -g 
Linkers:
  Static linker:   /usr/bin/ar cr
  Dynamic linker:   /Users/barrysmith/Src/petsc-dev/arch-gnu/bin/mpicc  
-dynamiclib -single_module -undefined dynamic_lookup -multiply_defined suppress 
 -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3
MPI:
  Includes: -I/Users/barrysmith/Src/petsc-dev/arch-gnu/include
X11:
  Includes: 
  Library:  -L/usr/X11R6/lib -lX11
BLAS/LAPACK: -llapack -lblas
c2html:
pthread:
sowing:
valgrind:
  Includes: -I/opt/local/include
PETSc:
  PETSC_ARCH: arch-gnu
  PETSC_DIR: /Users/barrysmith/Src/petsc-dev
  Clanguage: C
  Scalar type: real
  Precision: double
  Memory alignment: 16
  shared libraries: disabled
  dynamic loading: disabled
xxx=xxx
 Configure stage complete. Now build PETSc libraries with (legacy build):
   make PETSC_DIR=/Users/barrysmith/Src/petsc-dev PETSC_ARCH=arch-gnu all
 or (experimental with python):
   PETSC_DIR=/Users/barrysmith/Src/petsc-dev PETSC_ARCH=arch-gnu 
./config/builder.py
xxx=xxx
barry-smiths-macbook-pro:petsc-dev barrysmith$ make cmake
make -j 2 -C /Users/barrysmith/Src/petsc-dev/arch-gnu
Scanning dependencies of target petsc
Error copying Fortran module include/petscsys.  Tried include/PETSCSYS.mod 
and include/petscsys.mod.
make[4]: *** 
[CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides.build] Error 1
make[3]: *** [CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides] 
Error 2
make[2]: *** [CMakeFiles/petsc.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [cmake] Error 2

[petsc-dev] cmake problem

[Jed Brown]

Does make -C $PETSC_ARCH clean fix the problem. I don't know what caused
this in the first place. I'd rather not always have reconfigure clean
because it usually means needless compiling. I guess normal make clean
should clean the CMake part as well...
On Sep 23, 2011 5:23 PM, Barry Smith bsmith at mcs.anl.gov wrote:

 Jed,

 Please see the error below. What is the approved way to recover from
something incomprehensible to me like this? Shouldn't a reconfigure clean up
all possible dangers?

 Thanks

 Barry



 barry-smiths-macbook-pro:petsc-dev barrysmith$
./arch-gnu/conf/reconfigure-arch-gnu.py

===
 Configuring PETSc to compile on your system

===
 TESTING: alternateConfigureLibrary from
PETSc.packages.mpi4py(config/PETSc/packages/mpi4py.py:49) Compilers:
 C Compiler: /Users/barrysmith/Src/petsc-dev/arch-gnu/bin/mpicc -Wall
-Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3
 CUDA Compiler: nvcc -g
 Fortran Compiler: /Users/barrysmith/Src/petsc-dev/arch-gnu/bin/mpif90
-Wall -Wno-unused-variable -Wno-unused-dummy-argument -g
 Linkers:
 Static linker: /usr/bin/ar cr
 Dynamic linker: /Users/barrysmith/Src/petsc-dev/arch-gnu/bin/mpicc
-dynamiclib -single_module -undefined dynamic_lookup -multiply_defined
suppress -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3
 MPI:
 Includes: -I/Users/barrysmith/Src/petsc-dev/arch-gnu/include
 X11:
 Includes:
 Library: -L/usr/X11R6/lib -lX11
 BLAS/LAPACK: -llapack -lblas
 c2html:
 pthread:
 sowing:
 valgrind:
 Includes: -I/opt/local/include
 PETSc:
 PETSC_ARCH: arch-gnu
 PETSC_DIR: /Users/barrysmith/Src/petsc-dev
 Clanguage: C
 Scalar type: real
 Precision: double
 Memory alignment: 16
 shared libraries: disabled
 dynamic loading: disabled

xxx=xxx
 Configure stage complete. Now build PETSc libraries with (legacy build):
 make PETSC_DIR=/Users/barrysmith/Src/petsc-dev PETSC_ARCH=arch-gnu all
 or (experimental with python):
 PETSC_DIR=/Users/barrysmith/Src/petsc-dev PETSC_ARCH=arch-gnu
./config/builder.py

xxx=xxx
 barry-smiths-macbook-pro:petsc-dev barrysmith$ make cmake
 make -j 2 -C /Users/barrysmith/Src/petsc-dev/arch-gnu
 Scanning dependencies of target petsc
 Error copying Fortran module include/petscsys. Tried
include/PETSCSYS.mod and include/petscsys.mod.
 make[4]: ***
[CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides.build] Error
1
 make[3]: ***
[CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides] Error 2
 make[2]: *** [CMakeFiles/petsc.dir/all] Error 2
 make[1]: *** [all] Error 2
 make: *** [cmake] Error 2


-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110923/ec1b846d/attachment.html

[petsc-dev] cmake problem

[Barry Smith]

On Sep 23, 2011, at 5:54 PM, Jed Brown wrote:

 Does make -C $PETSC_ARCH clean fix the problem. I don't know what caused this 
 in the first place.

  I started a make without the cmake part then control-ced it because I 
didn't want to waste time for it (a thing that could happen all the time). 

 I'd rather not always have reconfigure clean because it usually means 
 needless compiling. I

At least have it clean up the Fortran module stuff?

 guess normal make clean should clean the CMake part as well...

   Absolutely

   Barry

 
 On Sep 23, 2011 5:23 PM, Barry Smith bsmith at mcs.anl.gov wrote:
  
  Jed,
  
  Please see the error below. What is the approved way to recover from 
  something incomprehensible to me like this? Shouldn't a reconfigure clean 
  up all possible dangers?
  
  Thanks
  
  Barry
  
  
  
  barry-smiths-macbook-pro:petsc-dev barrysmith$ 
  ./arch-gnu/conf/reconfigure-arch-gnu.py
  ===
  Configuring PETSc to compile on your system 
  ===
  TESTING: alternateConfigureLibrary from 
  PETSc.packages.mpi4py(config/PETSc/packages/mpi4py.py:49) Compilers:
  C Compiler: /Users/barrysmith/Src/petsc-dev/arch-gnu/bin/mpicc -Wall 
  -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 
  CUDA Compiler: nvcc -g 
  Fortran Compiler: /Users/barrysmith/Src/petsc-dev/arch-gnu/bin/mpif90 -Wall 
  -Wno-unused-variable -Wno-unused-dummy-argument -g 
  Linkers:
  Static linker: /usr/bin/ar cr
  Dynamic linker: /Users/barrysmith/Src/petsc-dev/arch-gnu/bin/mpicc 
  -dynamiclib -single_module -undefined dynamic_lookup -multiply_defined 
  suppress -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3
  MPI:
  Includes: -I/Users/barrysmith/Src/petsc-dev/arch-gnu/include
  X11:
  Includes: 
  Library: -L/usr/X11R6/lib -lX11
  BLAS/LAPACK: -llapack -lblas
  c2html:
  pthread:
  sowing:
  valgrind:
  Includes: -I/opt/local/include
  PETSc:
  PETSC_ARCH: arch-gnu
  PETSC_DIR: /Users/barrysmith/Src/petsc-dev
  Clanguage: C
  Scalar type: real
  Precision: double
  Memory alignment: 16
  shared libraries: disabled
  dynamic loading: disabled
  xxx=xxx
  Configure stage complete. Now build PETSc libraries with (legacy build):
  make PETSC_DIR=/Users/barrysmith/Src/petsc-dev PETSC_ARCH=arch-gnu all
  or (experimental with python):
  PETSC_DIR=/Users/barrysmith/Src/petsc-dev PETSC_ARCH=arch-gnu 
  ./config/builder.py
  xxx=xxx
  barry-smiths-macbook-pro:petsc-dev barrysmith$ make cmake
  make -j 2 -C /Users/barrysmith/Src/petsc-dev/arch-gnu
  Scanning dependencies of target petsc
  Error copying Fortran module include/petscsys. Tried 
  include/PETSCSYS.mod and include/petscsys.mod.
  make[4]: *** 
  [CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides.build] Error 
  1
  make[3]: *** 
  [CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides] Error 2
  make[2]: *** [CMakeFiles/petsc.dir/all] Error 2
  make[1]: *** [all] Error 2
  make: *** [cmake] Error 2
  
  

[petsc-dev] cmake --with-matlab build

[Satish Balay]

Jed,

Looks like cmake does not do part of the matlab build..


libfast in: /sandbox/balay/petsc-dev/src/sys/viewer/impls/socket/matlab
BEGINNING TO COMPILE MATLAB INTERFACE

Warning: You are using gcc version 4.4.3-4ubuntu5).  The version
 currently supported with MEX is 4.3.4.
 For a list of currently supported compilers see: 
 http://www.mathworks.com/support/compilers/current_release/


Warning: You are using gcc version 4.4.3-4ubuntu5).  The version
 currently supported with MEX is 4.3.4.
 For a list of currently supported compilers see: 
 http://www.mathworks.com/support/compilers/current_release/


Warning: You are using gcc version 4.4.3-4ubuntu5).  The version
 currently supported with MEX is 4.3.4.
 For a list of currently supported compilers see: 
 http://www.mathworks.com/support/compilers/current_release/


Warning: You are using gcc version 4.4.3-4ubuntu5).  The version
 currently supported with MEX is 4.3.4.
 For a list of currently supported compilers see: 
 http://www.mathworks.com/support/compilers/current_release/

libfast in: /sandbox/balay/petsc-dev/src/sys/viewer/impls/socket/ftn-custom


Satish

[petsc-dev] cmake --with-matlab build

[Satish Balay]

Perhaps we should pull it out to the toplevel 'matlab' target - which
does this build for both cases?

i.e

all:
  make all-cmake matlab
  or
  make all-legacy matlab

Also: [For Barry] from src/sys/viewer/impls/socket/matlab/makefile


sread:  
-@${MATLAB_MEX}  -g CC='${PCC}' CFLAGS='${COPTFLAGS} ${CC_FLAGS} 
${CCPPFLAGS}' sread.c bread.c -lc
-@${RM} -f sread.o bread.o
-@${MV} sread.mex* ${PETSC_DIR}/bin/matlab
,

Should these binaries be copied over to ${PETSC_DIR}/{PETSC_ARCH}/bin? 
[alternatively ${PETSC_DIR}/{PETSC_ARCH}/matlab/bin]

Satish



On Tue, 23 Aug 2011, Jed Brown wrote:

 IIRC, that part is basically shell script embedded in the makefile. If we
 make it structured, then the CMake build can do it, otherwise we would have
 to write a custom hack which would duplicate logic.
 On Aug 23, 2011 1:43 PM, Satish Balay balay at mcs.anl.gov wrote:
  Jed,
 
  Looks like cmake does not do part of the matlab build..
 
 
  libfast in: /sandbox/balay/petsc-dev/src/sys/viewer/impls/socket/matlab
  BEGINNING TO COMPILE MATLAB INTERFACE
 
  Warning: You are using gcc version 4.4.3-4ubuntu5). The version
  currently supported with MEX is 4.3.4.
  For a list of currently supported compilers see:
  http://www.mathworks.com/support/compilers/current_release/
 
 
  Warning: You are using gcc version 4.4.3-4ubuntu5). The version
  currently supported with MEX is 4.3.4.
  For a list of currently supported compilers see:
  http://www.mathworks.com/support/compilers/current_release/
 
 
  Warning: You are using gcc version 4.4.3-4ubuntu5). The version
  currently supported with MEX is 4.3.4.
  For a list of currently supported compilers see:
  http://www.mathworks.com/support/compilers/current_release/
 
 
  Warning: You are using gcc version 4.4.3-4ubuntu5). The version
  currently supported with MEX is 4.3.4.
  For a list of currently supported compilers see:
  http://www.mathworks.com/support/compilers/current_release/
 
  libfast in:
 /sandbox/balay/petsc-dev/src/sys/viewer/impls/socket/ftn-custom
  
 
  Satish
 
 

[petsc-dev] cmake --with-matlab build

[Barry Smith]

On Aug 23, 2011, at 3:54 PM, Satish Balay wrote:

 Perhaps we should pull it out to the toplevel 'matlab' target - which
 does this build for both cases?
 
 i.e
 
 all:
  make all-cmake matlab
  or
  make all-legacy matlab
 
 Also: [For Barry] from src/sys/viewer/impls/socket/matlab/makefile
 
 
 sread:  
-@${MATLAB_MEX}  -g CC='${PCC}' CFLAGS='${COPTFLAGS} ${CC_FLAGS} 
 ${CCPPFLAGS}' sread.c bread.c -lc
-@${RM} -f sread.o bread.o
-@${MV} sread.mex* ${PETSC_DIR}/bin/matlab
 ,
 
 Should these binaries be copied over to ${PETSC_DIR}/{PETSC_ARCH}/bin? 
 [alternatively ${PETSC_DIR}/{PETSC_ARCH}/matlab/bin]

  No, because MATLAB handles its own multiple arches itself so they can all be 
dumped in the same directory. And it saves the user mucking with adding yet 
another path to MATLABPATH.


   Barry

 
 Satish
 
 
 
 On Tue, 23 Aug 2011, Jed Brown wrote:
 
 IIRC, that part is basically shell script embedded in the makefile. If we
 make it structured, then the CMake build can do it, otherwise we would have
 to write a custom hack which would duplicate logic.
 On Aug 23, 2011 1:43 PM, Satish Balay balay at mcs.anl.gov wrote:
 Jed,
 
 Looks like cmake does not do part of the matlab build..
 
 
 libfast in: /sandbox/balay/petsc-dev/src/sys/viewer/impls/socket/matlab
 BEGINNING TO COMPILE MATLAB INTERFACE
 
 Warning: You are using gcc version 4.4.3-4ubuntu5). The version
 currently supported with MEX is 4.3.4.
 For a list of currently supported compilers see:
 http://www.mathworks.com/support/compilers/current_release/
 
 
 Warning: You are using gcc version 4.4.3-4ubuntu5). The version
 currently supported with MEX is 4.3.4.
 For a list of currently supported compilers see:
 http://www.mathworks.com/support/compilers/current_release/
 
 
 Warning: You are using gcc version 4.4.3-4ubuntu5). The version
 currently supported with MEX is 4.3.4.
 For a list of currently supported compilers see:
 http://www.mathworks.com/support/compilers/current_release/
 
 
 Warning: You are using gcc version 4.4.3-4ubuntu5). The version
 currently supported with MEX is 4.3.4.
 For a list of currently supported compilers see:
 http://www.mathworks.com/support/compilers/current_release/
 
 libfast in:
 /sandbox/balay/petsc-dev/src/sys/viewer/impls/socket/ftn-custom
 
 
 Satish
 
 
 

[petsc-dev] cmake --with-matlab build

[Satish Balay]

On Tue, 23 Aug 2011, Barry Smith wrote:

 
 On Aug 23, 2011, at 3:54 PM, Satish Balay wrote:
 
  Perhaps we should pull it out to the toplevel 'matlab' target - which
  does this build for both cases?
  
  i.e
  
  all:
   make all-cmake matlab
   or
   make all-legacy matlab
  
  Also: [For Barry] from src/sys/viewer/impls/socket/matlab/makefile
  
  
  sread:  
 -@${MATLAB_MEX}  -g CC='${PCC}' CFLAGS='${COPTFLAGS} ${CC_FLAGS} 
  ${CCPPFLAGS}' sread.c bread.c -lc
 -@${RM} -f sread.o bread.o
 -@${MV} sread.mex* ${PETSC_DIR}/bin/matlab
  ,
  
  Should these binaries be copied over to ${PETSC_DIR}/{PETSC_ARCH}/bin? 
  [alternatively ${PETSC_DIR}/{PETSC_ARCH}/matlab/bin]
 
   No, because MATLAB handles its own multiple arches itself so they can all 
 be dumped in the same directory. And it saves the user mucking with adding 
 yet another path to MATLABPATH.

But dumping generated files in PETSC_ARCH/bin? {PETSC_DIR}/{PETSC_ARCH}/bin is 
more appropriate for generated files.

[we could use this argument for mpiexec,bfort etc  - and dump them in 
PETSC_DIR/bin - but we don't]

Satish


 
 
Barry
 
  
  Satish
  
  
  
  On Tue, 23 Aug 2011, Jed Brown wrote:
  
  IIRC, that part is basically shell script embedded in the makefile. If we
  make it structured, then the CMake build can do it, otherwise we would have
  to write a custom hack which would duplicate logic.
  On Aug 23, 2011 1:43 PM, Satish Balay balay at mcs.anl.gov wrote:
  Jed,
  
  Looks like cmake does not do part of the matlab build..
  
  
  libfast in: /sandbox/balay/petsc-dev/src/sys/viewer/impls/socket/matlab
  BEGINNING TO COMPILE MATLAB INTERFACE
  
  Warning: You are using gcc version 4.4.3-4ubuntu5). The version
  currently supported with MEX is 4.3.4.
  For a list of currently supported compilers see:
  http://www.mathworks.com/support/compilers/current_release/
  
  
  Warning: You are using gcc version 4.4.3-4ubuntu5). The version
  currently supported with MEX is 4.3.4.
  For a list of currently supported compilers see:
  http://www.mathworks.com/support/compilers/current_release/
  
  
  Warning: You are using gcc version 4.4.3-4ubuntu5). The version
  currently supported with MEX is 4.3.4.
  For a list of currently supported compilers see:
  http://www.mathworks.com/support/compilers/current_release/
  
  
  Warning: You are using gcc version 4.4.3-4ubuntu5). The version
  currently supported with MEX is 4.3.4.
  For a list of currently supported compilers see:
  http://www.mathworks.com/support/compilers/current_release/
  
  libfast in:
  /sandbox/balay/petsc-dev/src/sys/viewer/impls/socket/ftn-custom
  
  
  Satish
  
  
  
 
 

[petsc-dev] cmake problem

[Barry Smith]

  Reran ./configure but then cmake made me trouble.  Sending the configure.log 
only to Jed

   Barry

xxx=xxx
 Configure stage complete. Now build PETSc libraries with:
   make PETSC_DIR=/Users/barrysmith/Src/petsc-dev PETSC_ARCH=arch-gnu all
 or (experimental with cmake):
   make -j4 -C /Users/barrysmith/Src/petsc-dev/arch-gnu
 or (experimental with python):
   PETSC_DIR=/Users/barrysmith/Src/petsc-dev PETSC_ARCH=arch-gnu 
./config/builder.py
xxx=xxx
cd /Users/barrysmith/Src/petsc-dev; make -j2 -C 
/Users/barrysmith/Src/petsc-dev/arch-gnu  


cd /Users/barrysmith/Src/petsc-dev; make -j2 -C 
/Users/barrysmith/Src/petsc-dev/arch-gnu
   
Scanning dependencies of target petsc
Error copying Fortran module include/petscsys.  Tried include/PETSCSYS.mod 
and include/petscsys.mod.
make[4]: *** 
[CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides.build] Error 1
make[3]: *** [CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides] 
Error 2
make[2]: *** [CMakeFiles/petsc.dir/all] Error 2
make[1]: *** [all] Error 2
make: *** [cmake] Error 2
anlextwls002-241:petsc-dev barrysmith$ echo $PETSC_DIR
/Users/barrysmith/Src/petsc-dev

[petsc-dev] cmake problem

[Jed Brown]

On Fri, Jul 8, 2011 at 14:28, Barry Smith bsmith at mcs.anl.gov wrote:


  Reran ./configure but then cmake made me trouble.  Sending the
 configure.log only to Jed

   Barry


 xxx=xxx
  Configure stage complete. Now build PETSc libraries with:
   make PETSC_DIR=/Users/barrysmith/Src/petsc-dev PETSC_ARCH=arch-gnu all
  or (experimental with cmake):
   make -j4 -C /Users/barrysmith/Src/petsc-dev/arch-gnu
  or (experimental with python):
   PETSC_DIR=/Users/barrysmith/Src/petsc-dev PETSC_ARCH=arch-gnu
 ./config/builder.py

 xxx=xxx
 cd /Users/barrysmith/Src/petsc-dev; make -j2 -C
 /Users/barrysmith/Src/petsc-dev/arch-gnu


 cd /Users/barrysmith/Src/petsc-dev; make -j2 -C
 /Users/barrysmith/Src/petsc-dev/arch-gnu
 Scanning dependencies of target petsc
 Error copying Fortran module include/petscsys.  Tried
 include/PETSCSYS.mod and include/petscsys.mod.
 make[4]: ***
 [CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides.build] Error
 1
 make[3]: ***
 [CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides] Error 2
 make[2]: *** [CMakeFiles/petsc.dir/all] Error 2
 make[1]: *** [all] Error 2
 make: *** [cmake] Error 2
 anlextwls002-241:petsc-dev barrysmith$ echo $PETSC_DIR
 /Users/barrysmith/Src/petsc-dev



-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110708/ea1192df/attachment.html

[petsc-dev] cmake problem

[Jed Brown]

On Fri, Jul 8, 2011 at 14:28, Barry Smith bsmith at mcs.anl.gov wrote:

 cd /Users/barrysmith/Src/petsc-dev; make -j2 -C
 /Users/barrysmith/Src/petsc-dev/arch-gnu
 Scanning dependencies of target petsc
 Error copying Fortran module include/petscsys.  Tried
 include/PETSCSYS.mod and include/petscsys.mod.
 make[4]: ***
 [CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides.build] Error
 1
 make[3]: ***
 [CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides] Error 2


I don't understand why this is, but does

make -C arch-gnu clean petsc

get you a working build?
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110708/aa5fde68/attachment.html

[petsc-dev] cmake problem

[Barry Smith]

  Seems to have worked, thanks.

   Barry

On Jul 8, 2011, at 3:54 PM, Jed Brown wrote:

 On Fri, Jul 8, 2011 at 14:28, Barry Smith bsmith at mcs.anl.gov wrote: 
 cd /Users/barrysmith/Src/petsc-dev; make -j2 -C 
 /Users/barrysmith/Src/petsc-dev/arch-gnu
 Scanning dependencies of target petsc
 Error copying Fortran module include/petscsys.  Tried 
 include/PETSCSYS.mod and include/petscsys.mod.
 make[4]: *** 
 [CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides.build] Error 1
 make[3]: *** [CMakeFiles/petsc.dir/src/sys/f90-mod/petscsysmod.F.o.provides] 
 Error 2
 
 I don't understand why this is, but does
 
 make -C arch-gnu clean petsc
 
 get you a working build?
 

[petsc-dev] CMake broken

[Jose E. Roman]

CMake build is broken in the latest petsc-dev: cmakeboot does not generate the 
makefiles.

I have made a bisection search and found this changeset in BuildSystem:
http://petsc.cs.iit.edu/petsc/BuildSystem/rev/bbad23803405

If I uncomment the line USE_SUBPROCESS = 0 in config/Buildsystem/script.py then 
it works again.

Jose

[petsc-dev] CMake broken

[Satish Balay]

pushed the change.

satish

On Wed, 11 May 2011, Barry Smith wrote:

 
That is my fault. I messed with that SUBPROCESS file a long time ago and 
 forgot I changed it, then when I put in proper changes I left that bad change.
 
 Satish, can you remove the comment of the subprocess stuff and push?
 
 Thanks
 
 Barry
 
 On May 11, 2011, at 7:51 AM, Jose E. Roman wrote:
 
  CMake build is broken in the latest petsc-dev: cmakeboot does not generate 
  the makefiles.
  
  I have made a bisection search and found this changeset in BuildSystem:
  http://petsc.cs.iit.edu/petsc/BuildSystem/rev/bbad23803405
  
  If I uncomment the line USE_SUBPROCESS = 0 in config/Buildsystem/script.py 
  then it works again.
  
  Jose
  
 
 

[petsc-dev] cmake and fortranstubs

[Barry Smith]

On Dec 1, 2010, at 11:48 AM, Jed Brown wrote:

 On Wed, Dec 1, 2010 at 18:24, Barry Smith bsmith at mcs.anl.gov wrote:
 It would be nice if cmake also updated the appropriate fortranstubs.
 
 Make generatefortranstubs.py have a way to update individual files and I will 
 make cmake do the generated files automatically.  I might do it anyway, but 
 this is the more elegant solution.

  Jed,

It cannot do a single file but it can now do a single directory. So you can 
now add support for cmake for this. Note that the generating stubs can be done 
in parallel assuming different root directories, only the -merge step must be 
done sequentially.

   Barry


generatefortranstubs.py bfortexecutable -- generates Fortran stubs for a 
directory and all children directories
generatefortranstubs.py -merge  -- run after all stubs are generated to merge 
include files in include/finclude/ftn-auto

thus

generatefortranstubs.py bfortexecutable
generatefortranstubs.py -merge

in the PETSC_DIR replaces the previous

generatefortranstubs.py bfortexecutable



 
 Once you develop something that does things automatically people will 
 always demand, more, more, more
 
 This is the essence of computing.
 
 Jed

[petsc-dev] cmake and fortranstubs

[Barry Smith]

...
[ 87%] Building C object 
CMakeFiles/petsc.dir/src/ksp/pc/impls/gasm/ftn-auto/gasmf.c.o
[ 88%] Building C object 
CMakeFiles/petsc.dir/src/ksp/pc/impls/composite/ftn-auto/compositef.c.o
/Users/barrysmith/Src/petsc-dev/src/ksp/pc/impls/gasm/ftn-auto/gasmf.c: In 
function ?pcgasmcreatesubdomains2d_?:
/Users/barrysmith/Src/petsc-dev/src/ksp/pc/impls/gasm/ftn-auto/gasmf.c:69: 
warning: passing argument 1 of ?PCGASMCreateSubdomains2D? makes pointer from 
integer without a cast
/Users/barrysmith/Src/petsc-dev/src/ksp/pc/impls/gasm/ftn-auto/gasmf.c:69: 
warning: passing argument 7 of ?PCGASMCreateSubdomains2D? makes integer from 
pointer without a cast
/Users/barrysmith/Src/petsc-dev/src/ksp/pc/impls/gasm/ftn-auto/gasmf.c:69: 
warning: passing argument 8 of ?PCGASMCreateSubdomains2D? from incompatible 
pointer type
/Users/barrysmith/Src/petsc-dev/src/ksp/pc/impls/gasm/ftn-auto/gasmf.c:69: 
error: too few arguments to function ?PCGASMCreateSubdomains2D?
make[2]: *** [CMakeFiles/petsc.dir/src/ksp/pc/impls/gasm/ftn-auto/gasmf.c.o] 
Error 1
make[2]: *** Waiting for unfinished jobs

It would be nice if cmake also updated the appropriate fortranstubs.

   Barry

Once you develop something that does things automatically people will always 
demand, more, more, more

[petsc-dev] cmake and fortranstubs

[Jed Brown]

On Wed, Dec 1, 2010 at 18:24, Barry Smith bsmith at mcs.anl.gov wrote:

 It would be nice if cmake also updated the appropriate fortranstubs.


Make generatefortranstubs.py have a way to update individual files and I
will make cmake do the generated files automatically.  I might do it anyway,
but this is the more elegant solution.

Once you develop something that does things automatically people will
 always demand, more, more, more


This is the essence of computing.

Jed
-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20101201/b824ca0a/attachment.html

[petsc-dev] cmake issue

[Lisandro Dalcin]

Jed, I had a file  src/mat/impls/schur/ftn-auto/schurmf.c around
coming from old builds, I did not noticed it until now because of
hgignore . Trying to build with cmake failed because it tried to
compile that outdated file. Not a big deal, but I'm wondering if it
would be easy to fix?

-- 
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

[petsc-dev] cmake issue

[Jed Brown]

On Mon, Oct 4, 2010 at 14:21, Lisandro Dalcin dalcinl at gmail.com wrote:
 Jed, I had a file ?src/mat/impls/schur/ftn-auto/schurmf.c around
 coming from old builds, I did not noticed it until now because of
 hgignore . Trying to build with cmake failed because it tried to
 compile that outdated file. Not a big deal, but I'm wondering if it
 would be easy to fix?

I have CMake automatically picking up the files in ftn-auto
directories when Fortran is enabled (note that the makefiles in
ftn-auto directories are also auto-generated).  If it was just a stale
file in the ftn-auto directory, the next time you ran configure (or
make allfortranstubs), it would be removed.  The problem here is that
the whole impls/schur directory disappeared (2 years ago) when
MatSchur was moved to KSP where it belongs.  Just delete this ancient
directory and reconfigure (or run config/cmakegen.py) and it should
work.  Let me know if you have any problem with this.

Jed

[petsc-dev] cmake issue

[Lisandro Dalcin]

On 4 October 2010 10:51, Jed Brown five9a2 at gmail.com wrote:
 On Mon, Oct 4, 2010 at 14:21, Lisandro Dalcin dalcinl at gmail.com wrote:
 Jed, I had a file ?src/mat/impls/schur/ftn-auto/schurmf.c around
 coming from old builds, I did not noticed it until now because of
 hgignore . Trying to build with cmake failed because it tried to
 compile that outdated file. Not a big deal, but I'm wondering if it
 would be easy to fix?

 I have CMake automatically picking up the files in ftn-auto
 directories when Fortran is enabled (note that the makefiles in
 ftn-auto directories are also auto-generated). ?If it was just a stale
 file in the ftn-auto directory, the next time you ran configure (or
 make allfortranstubs), it would be removed. ?The problem here is that
 the whole impls/schur directory disappeared (2 years ago) when
 MatSchur was moved to KSP where it belongs. ?Just delete this ancient
 directory and reconfigure (or run config/cmakegen.py) and it should
 work. ?Let me know if you have any problem with this.

 Jed


Well, from 2 years ago up to now, I've reconfigured many times. It
seems the ftn-auto directory was not automatically removed.



-- 
Lisandro Dalcin
---
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

[petsc-dev] cmake issue

[Jed Brown]

On Mon, Oct 4, 2010 at 18:39, Lisandro Dalcin dalcinl at gmail.com wrote:
 Well, from 2 years ago up to now, I've reconfigured many times. It
 seems the ftn-auto directory was not automatically removed.

That is because the *parent* of the ftn-auto directory was deleted
from Hg.  I could actually parse the makefile to find subdirectories
to recurse into, but builder.py doesn't do that either and it's
slightly messy to do robustly (or maybe we should use
distutils.sysconfig).  cmakegen.py does check makefiles for #requires
lines, but not for source and directory lines.

Jed

[petsc-dev] cmake issue

[Jed Brown]

On Mon, Oct 4, 2010 at 18:48, Jed Brown jed at 59a2.org wrote:
 On Mon, Oct 4, 2010 at 18:39, Lisandro Dalcin dalcinl at gmail.com wrote:
 Well, from 2 years ago up to now, I've reconfigured many times. It
 seems the ftn-auto directory was not automatically removed.

 That is because the *parent* of the ftn-auto directory was deleted
 from Hg. ?I could actually parse the makefile to find subdirectories
 to recurse into, but builder.py doesn't do that either and it's
 slightly messy to do robustly (or maybe we should use
 distutils.sysconfig).

I implemented this, cmakegen.py no longer explores directories that
are not listed in the makefiles (except for the auto directories,
just like make).

Jed

[petsc-dev] CMake proof of concept

[Jed Brown]

On Mon, 31 May 2010 19:13:07 -0500, Barry Smith bsmith at mcs.anl.gov wrote:
 
You have an awful lot of confidence in cmake. I have no problem at
 all setting up a system where PETSc can use cmake, that's great. But I
 don't want PETSc to ever be in a position of not being able to do
 something because kitware/whatever decided that they no longer or
 would not supported xyz or we have to wait six months for them to
 port to a new system.

This is legitimate and obscure hardware/compilers is a big reason why
CMake has no business being the only build system for PETSc.  Given
make's failings on Windows or whatever, maybe builder.py will be able to
fill the role of canonical build system.

But in the world of IDE integration, I think they are way ahead because
quite a number of IDEs have written explicit support for CMake, in the
sense that you just point it to the project root and a set of build
directories and automatically get proper source analysis (including
correct macro expansion when you switch PETSC_ARCH from the menu), all
the relevant build targets, debug profiles, etc.  Since most IDEs have
already bought in, I think it is a reasonable language for talking to
them, and suspect that direct PETSc/BuildSystem - IDE-X links will be
unnecessary.

Jed

[petsc-dev] CMake proof of concept

[Jed Brown]

In this latest buzz about build systems and IDE integration, I added a
CMake build to PETSc.  It is entirely contained in bin/maint/cmakegen.py
and bin/maint/cmakeboot.py and supports multiple PETSC_ARCH, Fortran,
C++ (currently only with-c-support), complex/precision/etc, with and
without single-library, static or shared, and coexists with the existing
build system.  The primary motivation for this was (a) dependency
analysis, (b) parallel builds, (c) IDE integration, (d) more
sophisticated test summaries (later, maybe,
cf. http://public.kitware.com/dashboard.php).

Usage:
After generating ftn-auto if necessary, run

  bin/maint/cmakegen.py

which creates a PETSC_ARCH-agnostic $PETSC_DIR/CMakeLists.txt which
describes the build in terms of the variables that might be set by each
PETSC_ARCH (I put it all in one file so as to be as unintrusive as
possible).  This might need to be rerun after pulling new sources, but
it is fast (1 second).

Then, after running configure for your given PETSC_ARCH, run

  bin/maint/cmakeboot.py

which initializes CMake's build in that directory.  This normally only
needs to be run once, CMake's cache and dependencies will be updated as
necessary (e.g. a source file includes different headers or
CMakeLists.txt changes after rerunning cmakegen.py).  This script
accepts arguments to be passed on to CMake, such as

  -G'Eclipse CDT4 - Unix Makefiles'

which creates an Eclipse project file with an accompanying
Makefile-based build.  I've tested import with Eclipse, KDevelop, and Qt
Creator; a variety of other IDEs are supported (including XCode and
Visual Studio) but I don't use those platforms so can't test them).
Note that most IDEs have a way to manage multiple build
configurations, which correspond to multiple values of PETSC_ARCH.
Usually you point them to $PETSC_DIR/CMakeLists.txt and then specify a
build directory which would be $PETSC_DIR/$PETSC_ARCH for whichever
configurations you want.

Both of these steps should be very fast and idempotent.  At this point,
the values of PETSC_DIR and PETSC_ARCH (in your environment) are no
longer of any consequence, everything is determined by the location of
the build directory.  Managing multiple builds is easy, for example,
just run (assuming a Makefile based build)

  $ make -C arch1 -j3   make -C arch2 -j5 

to update the libraries for multiple configurations at once with several
processes each.  The object files reside in $PETSC_ARCH/CMakeFiles so
their presence doesn't interfere with other builds and refreshing is
fast (only rebuild when necessary, do-nothing rebuild takes less than 1
second without single-library, a slightly more with single-library).

I currently don't do anything with examples, I suggest building them as
usual with PETSc's current system until/unless they are added to this.
I haven't provided a public PETScConfig.cmake and haven't addressed
installation.


I declared a CMake compatibility version of 2.6 because that's the
oldest I've tested.  The scripts cmakegen.py and cmakeboot.py require
Python 2.5 because I wanted newer language features.  It could easily be
ported to older pythons if that became important, but the whole thing is
just a proof of concept at this stage.  These versions are not hard to
come by and I would imagine that everyone's development machine is
relatively current.

Let me know about any issues.

Jed

[petsc-dev] CMake proof of concept

[Barry Smith]

   Likely we need a subdirectory somewhere to put all the make makers. I would 
like a subdirectory of bin/maint; likely Matt wants a subdirectory of config

   Currently config is almost all just config stuff, but Matt put his 
builder.py that makes in there. I don't object to having the make stuff in 
config except then it shouldn't be called config anymore. Perhaps there should 
be a make directory at the top level? But then does the conf stuff go, into 
that make directory?

config/ all configure stuff
PETSc
BuildSystem
make (or build?)/  all make stuff
   conf   need better name; what is currently 
in conf   - this is class makestuff
   cmake   for Jed's C make
   Matt   for Matt's builder.py
   other for iphonebuilder.py etc
   scripts or bin   for allfortranstubs.py and similar beasts



Barry

On May 31, 2010, at 10:23 AM, Jed Brown wrote:

 In this latest buzz about build systems and IDE integration, I added a
 CMake build to PETSc.  It is entirely contained in bin/maint/cmakegen.py
 and bin/maint/cmakeboot.py and supports multiple PETSC_ARCH, Fortran,
 C++ (currently only with-c-support), complex/precision/etc, with and
 without single-library, static or shared, and coexists with the existing
 build system.  The primary motivation for this was (a) dependency
 analysis, (b) parallel builds, (c) IDE integration, (d) more
 sophisticated test summaries (later, maybe,
 cf. http://public.kitware.com/dashboard.php).
 
 Usage:
 After generating ftn-auto if necessary, run
 
  bin/maint/cmakegen.py
 
 which creates a PETSC_ARCH-agnostic $PETSC_DIR/CMakeLists.txt which
 describes the build in terms of the variables that might be set by each
 PETSC_ARCH (I put it all in one file so as to be as unintrusive as
 possible).  This might need to be rerun after pulling new sources, but
 it is fast (1 second).
 
 Then, after running configure for your given PETSC_ARCH, run
 
  bin/maint/cmakeboot.py
 
 which initializes CMake's build in that directory.  This normally only
 needs to be run once, CMake's cache and dependencies will be updated as
 necessary (e.g. a source file includes different headers or
 CMakeLists.txt changes after rerunning cmakegen.py).  This script
 accepts arguments to be passed on to CMake, such as
 
  -G'Eclipse CDT4 - Unix Makefiles'
 
 which creates an Eclipse project file with an accompanying
 Makefile-based build.  I've tested import with Eclipse, KDevelop, and Qt
 Creator; a variety of other IDEs are supported (including XCode and
 Visual Studio) but I don't use those platforms so can't test them).
 Note that most IDEs have a way to manage multiple build
 configurations, which correspond to multiple values of PETSC_ARCH.
 Usually you point them to $PETSC_DIR/CMakeLists.txt and then specify a
 build directory which would be $PETSC_DIR/$PETSC_ARCH for whichever
 configurations you want.
 
 Both of these steps should be very fast and idempotent.  At this point,
 the values of PETSC_DIR and PETSC_ARCH (in your environment) are no
 longer of any consequence, everything is determined by the location of
 the build directory.  Managing multiple builds is easy, for example,
 just run (assuming a Makefile based build)
 
  $ make -C arch1 -j3   make -C arch2 -j5 
 
 to update the libraries for multiple configurations at once with several
 processes each.  The object files reside in $PETSC_ARCH/CMakeFiles so
 their presence doesn't interfere with other builds and refreshing is
 fast (only rebuild when necessary, do-nothing rebuild takes less than 1
 second without single-library, a slightly more with single-library).
 
 I currently don't do anything with examples, I suggest building them as
 usual with PETSc's current system until/unless they are added to this.
 I haven't provided a public PETScConfig.cmake and haven't addressed
 installation.
 
 
 I declared a CMake compatibility version of 2.6 because that's the
 oldest I've tested.  The scripts cmakegen.py and cmakeboot.py require
 Python 2.5 because I wanted newer language features.  It could easily be
 ported to older pythons if that became important, but the whole thing is
 just a proof of concept at this stage.  These versions are not hard to
 come by and I would imagine that everyone's development machine is
 relatively current.
 
 Let me know about any issues.
 
 Jed

[petsc-dev] CMake proof of concept

[Jed Brown]

On Mon, 31 May 2010 11:10:36 -0500, Barry Smith bsmith at mcs.anl.gov wrote:
 
Likely we need a subdirectory somewhere to put all the make makers. I 
 would like a subdirectory of bin/maint; likely Matt wants a subdirectory of 
 config

Is this really important?  It doesn't seem that messy at this point and
I don't see the advantage of deep hierarchies, /usr/bin has several
thousand executables, but it doesn't bother me.  I don't have a problem
with the current setup except that I don't think builder.py should be in
config.

Also note that iphonebuilder.py might not be strictly necessary:

  
http://sites.google.com/site/michaelsafyan/coding/resources/how-to-guides/cross-compile-for-the-iphone/how-to-cross-compile-for-the-iphone-using-cmake

I don't know how this will all shake out, but I don't imagine there will
ever be a lot of these scripts purely for maintenance and support
reasons.  For instance, I could imagine only having a single builder.py
to just build everything without any external dependencies and CMake for
IDE integration.

Jed

[petsc-dev] CMake proof of concept

[Barry Smith]

   You have an awful lot of confidence in cmake. I have no problem at all 
setting up a system where PETSc can use cmake, that's great. But I don't want 
PETSc to ever be in a position 
of not being able to do something because kitware/whatever decided that they no 
longer or would not  supported xyz or we have to wait six months for them to 
port to a new system.

   From the point of view of using /usr/bin I don't care that there are 
thousands of crazy ass things in it. If I were maintaining it I would insist on 
proper organization. So I am noting thinking of my proposed organization as for 
the user but instead for the maintainers.


   Barry



On May 31, 2010, at 11:46 AM, Jed Brown wrote:

 On Mon, 31 May 2010 11:10:36 -0500, Barry Smith bsmith at mcs.anl.gov wrote:
 
   Likely we need a subdirectory somewhere to put all the make makers. I 
 would like a subdirectory of bin/maint; likely Matt wants a subdirectory of 
 config
 
 Is this really important?  It doesn't seem that messy at this point and
 I don't see the advantage of deep hierarchies, /usr/bin has several
 thousand executables, but it doesn't bother me.  I don't have a problem
 with the current setup except that I don't think builder.py should be in
 config.
 
 Also note that iphonebuilder.py might not be strictly necessary:
 
  
 http://sites.google.com/site/michaelsafyan/coding/resources/how-to-guides/cross-compile-for-the-iphone/how-to-cross-compile-for-the-iphone-using-cmake
 
 I don't know how this will all shake out, but I don't imagine there will
 ever be a lot of these scripts purely for maintenance and support
 reasons.  For instance, I could imagine only having a single builder.py
 to just build everything without any external dependencies and CMake for
 IDE integration.
 
 Jed