26 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: Git repo with CMake available

I have started to update my nightly-build script.  I managed to run and test oofem debug target. However, when trying to configure and build parallel version, I have recognized, that probably different Petsc configuration has to be followed, as the default one does not produces the PETScConfig.cmake and petsc-config.cmake files. Does this mean that we need to run PETSc configure with " --with-cmake=/path/to/cmake" option?

If yes, we have to update intallation instruction on oofem wiki (we have to do it anyway, as they still refer to old procedure).
Another thing: I have noticed that cmake generates various make targets for nightly builds. Can this be easily customized and used instead?

bp's Website

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: Git repo with CMake available

I changed the default to just use the static libs, so everything should work automatically on OSX now (except that you have to specify the path if you wish for a certain X lib to be used).

I'll try to fix that dynamic lib problem (I think its just that dylib on mac doesn't like externally defined variables, i.e. classFactory, oofem_logger, oofem_errLogger ).
Probably as simple as; classFactory should just be moved into classFactory.h, the error log variables moved into logger.h

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: Git repo with CMake available

When I have compiled PETSc i've just done the usual "./configure; make", but since I had CMake installed and available in $PATH, it was used automatically.


The "NightlyBuild" targets, etc,  are mainly supposed to be connected to http://www.cdash.org/. If one sets up a dashboard, different computers would run the nightly build target and the dashboard aggregates the results (so, one nightly build coming from OSX, one from Linux, varying configuration options, etc.)
Basically resulting in something like http://open.cdash.org/index.php?project=calaTK
The targets appear automatically when I use CTest, so I didn't intentionally add them (and if we aren't going to bother with CDash, I'm sure its possible to turn them off).
I'm not sure if they are that useful outside of CDash. "make Nightly"  will check out the latest version, configure it, build it, test it, and while doing so, print some basic information on screen, and write the detailed warnings and errors produced in a XML-file. (which is what is sent to CDash)

$ make Experimental
   Site: debian                                                                                                                                                      
   Build name: Linux-c++                                                                                                                                             
Create new tag: 20121214-1715 - Experimental                                                                                                                         
Configure project                                                                                                                                                    
   Each . represents 1024 bytes of output                                                                                                                            
    . Size of output: 0K                                                                                                                                             
Build project                                                                                                                                                        
   Each symbol represents 1024 bytes of output.                                                                                                                      
   '!' represents an error and '*' a warning.                                                                                                                        
    .**********..**.*.*....**...*..**..*..............  Size: 49K                                                                                                    
     Size of output: 49K                                                                                                                                             
   0 Compiler errors                                                                                                                                                 
   50 or more Compiler warnings                                                                                              
......

and then it goes on to testing (i will replace the build name with something more useful)

B.t.w, I didn't figure out any simple way to skip the cemhyd tests if CemHyd isn't compiled, and its off by default (since it introduces another dependency).

29 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,047

Re: Git repo with CMake available

Just some notes for future work:
- right now, the cmake build script requires to build shared PETSC libraries, the default is to build static ones. In this case compilation will fail, so we have to use "--with-shared-libraries" when configuring PETSc.
- parallel tests are not run correctly, only the serial version of parallel tests is run, not the parallel ones.

bp's Website

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: Git repo with CMake available

1. I made the cmake file more general, it should be able to find either libpetsc.a or libpetsc.so now
http://www.oofem.org/gitweb/?p=oofem.gi … 6effadd956

2. When compiling with parallel support, I just viewed this as an addition to OOFEM (just like any other feature), so I didn't change the name of the binary to "poofem", but the parallel build does run the parallel tests.
Instead of "poofem" one could use a flag "-p" for parallel runs (in fact, that code is already there since quite some time. It's just that -p is automatically on whenever parallel support is on to keep it backwards compatible), and then oofem would be able to solve sequential and parallel jobs in the same binary.
I just added the (currently redundant) flag "-p" to the parallel test suite so it works if we change the default parallel build behavior.

Sorry about that confusion, I forgot to mention that.