Multiple targets in CMake would be done by simply configuring in different directories (CMake does out-of-tree builds)
I have 3 of them set up myself
~/build/debug
~/build/release
~/build/parallel
all configured from the source directory in ~/projects/oofem/

I will make a wiki page.

(Disclaimer; I have only tested the *.deb package, and petsc 3.3 is still missing from debian)

Is it OK if I push the CMake scripts to the developer branch?

Ok, so I went through and made sure OOFEG was compiling (had to add some libraries). Not sure how to use it, but it compiles and links fine.

I also haven't really tried out the python bindings yet (but it does compile and link just fine). I need to tell cmake to bake a shared library out of everything.
Preferably, I would want to take everything from sm, fm, tm, oofemlib, and always make a liboofem.[a,so] out of it, then link the executeable to that.
That way, python bindings would just be one more optional feature of the oofem library, and not a separate entity.

(also, to avoid confusion, i renamed the "oofemlib" module to "core" inside the build scripts, and eventually, I was thinking about renmaing the actual src/oofemlib folder as well)

I cleared out the autotools build scripts. If all goes well, I'll push to the develop branch tomorrow

I believe everything is in working order now, so I thought I'd push to develop branch. I just wanted to give everyone a heads up. I'll push it tomorrow evening unless there are any objections.

There are now options for compiling static or shared libraries (or both), and oofeg+oofem can be compiled with the same configuration, and they link to the same shared library (which includes all modules, so libfm.a libsm.a libtm.a doesn't exists anymore, just a big library for everything).
Internally, i call oofemlib -> core, to not confuse it with the new main target: liboofem.[a|so] which contains everything.

The modules have cross-dependencies and such so it doesn't make much sense in trying to build them in different libraries.

(I'm still not sure exactly how the python bindings are should be compiled).

I have tested the new cmake setup in the master branch on my mac.
No problem with oofem once I set shared libraries to off.
However, cannot link oofeg. See message below:

Undefined symbols for architecture x86_64:
  "_XtNameToWidget", referenced from:
      set_layer_on_off(EView*, char*, CkitPoint3Struct*) in oofeg.C.o
      updateDefPlotFlag()     in oofeg.C.o
      straincompPlot(_WidgetRec*, void*, void*)in oofeg.C.o
      stresscompPlot(_WidgetRec*, void*, void*)in oofeg.C.o
      apply_layer_update(_WidgetRec*, void*, void*)in oofeg.C.o
      apply_mat_reg_filter(_WidgetRec*, void*, void*)in oofeg.C.o
      _apply_change in libesi.a(simple1.o)
      ...

And many more. At the end:

ld: symbol(s) not found for architecture x86_64

collect2: ld returned 1 exit status
make[2]: *** [oofeg] Error 1
make[1]: *** [CMakeFiles/oofeg.dir/all] Error 2
make: *** [all] Error 2

Any idea what one could try.

For oofem I get this error message when i just run the default settings:

===============================================================
===============================================================
Scanning dependencies of target liboofem
[100%] Building CXX object CMakeFiles/liboofem.dir/src/main/usrdefsub.C.o
[100%] Building CXX object CMakeFiles/liboofem.dir/src/main/classfactory.C.o
Linking CXX shared library liboofem.dylib
Undefined symbols for architecture x86_64:
  "oofem::classFactory", referenced from:
      oofem::CreateUsrDefElementOfType(char const*, int, oofem::Domain*)in usrdefsub.C.o
      oofem::CreateUsrDefRandomFieldGenerator(oofem::classType, int, oofem::Domain*)in usrdefsub.C.o
      oofem::CreateUsrDefRandomFieldGenerator(char const*, int, oofem::Domain*)in usrdefsub.C.o
      oofem::CreateUsrDefNonlocalBarrierOfType(oofem::classType, int, oofem::Domain*)in usrdefsub.C.o
      oofem::CreateUsrDefNonlocalBarrierOfType(char const*, int, oofem::Domain*)in usrdefsub.C.o
      oofem::CreateUsrDefLoadTimeFunctionOfType(oofem::classType, int, oofem::Domain*)in usrdefsub.C.o
      oofem::CreateUsrDefLoadTimeFunctionOfType(char const*, int, oofem::Domain*)in usrdefsub.C.o
      ...
  "oofem::oofem_errLogger", referenced from:
      oofem::CreateUsrDefNodalRecoveryModel(oofem::NodalRecoveryModel::NodalRecoveryModelType, oofem::Domain*)in usrdefsub.C.o
      oofem::CreateUsrDefGeometry(oofem::classType)   in usrdefsub.C.o
      oofem::CreateUsrDefEnrichmentFunction(oofem::classType, int, oofem::Domain*)in usrdefsub.C.o
      oofem::CreateUsrDefEnrichmentItem(oofem::classType, int, oofem::XfemManager*, oofem::Domain*)in usrdefsub.C.o
      oofem::CreateUsrDefPatch(oofem::Patch::PatchType, oofem::Element*)in usrdefsub.C.o
      oofem::CreateUsrDefMesherInterface(oofem::MeshPackageType, oofem::Domain*)in usrdefsub.C.o
      oofem::CreateUsrDefMaterialMappingAlgorithm(oofem::MaterialMappingAlgorithmType)    in usrdefsub.C.o
      ...
  "oofem::oofem_logger", referenced from:
      oofem::DynCompRow::ILUPYourself(int, double)in dyncomprow.C.o
      oofem::DynCompRow::buildInternalStructure(oofem::EngngModel*, int, oofem::EquationID, oofem::UnknownNumberingScheme const&)in dyncomprow.C.o
      oofem::SparseMtrx::printYourself() const in dyncomprow.C.o
      oofem::SparseMtrx::printStatistics() const in dyncomprow.C.o
      oofem::SparseMtrx::writeToFile(char const*) constin dyncomprow.C.o
      oofem::DynCompCol::buildInternalStructure(oofem::EngngModel*, int, oofem::EquationID, oofem::UnknownNumberingScheme const&)in dyncompcol.C.o
      oofem::DynCompCol::printStatistics() const in dyncompcol.C.o
      ...
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[3]: *** [liboofem.dylib] Error 1
make[2]: *** [CMakeFiles/liboofem.dir/all] Error 2
make[1]: *** [CMakeFiles/oofem.dir/rule] Error 2
make: *** [oofem] Error 2
=======================================================
=======================================================

By switching off shared libraries it works.

I will look now at the flags for oofeg. It worked before the transition to cmake.
So, should be possible to sort it out.

So it seems you have some X11 libraries in /usr/X11/lib that CMake finds by default.
Could you verify this by checking for example

file /usr/X11/lib/libXaw.dylib

But you probably want to use the custom libraries in /opt/local/lib/ instead, so I suppose I should add a parameter for that in the cmake scripts.
I added a parameter X11_DIR which you can set when configuring (/opt/local/lib/ should work in your case).
Could you try out the updated CMakeLists.txt attached here to see if that sorts out the problems?

For the dynamic library problem, could you again check the actual link flags using VERBOSE?

Hmm. Ok.
Long explanation;
So I use the CMake module
find_package(X11 ...)
to find the suitable X11-libraries to link with. I was incorrect when i tried to add to the PATH option did for find_package (instead of adding a search path for the libraries, it adds a search path for the cmake file)
find_package will in the case on my computer run /usr/share/cmake-2.8/FindX11.cmake
which uses some hardcoded values;

  SET(X11_LIB_SEARCH_PATH
    /usr/pkg/xorg/lib
    /usr/X11R6/lib
    /usr/X11R7/lib
    /usr/openwin/lib
  )

and then runs the following find_library commands for all the X11 libs

  FIND_LIBRARY(X11_ICE_LIB ICE               ${X11_LIB_SEARCH_PATH})
  FIND_LIBRARY(X11_SM_LIB SM                 ${X11_LIB_SEARCH_PATH})
....

The find_library function also includes the system default paths (since none of the specified paths match), so I can only imagine that you actually list /opt/local/lib/ somewhere that the compiler can find automatically.
Luckily it should be possible to tell CMake what to use for these default paths and bypass the /opt/local/lib/ path

You need to set

CMAKE_LIBRARY_PATH=/usr/lib/X11/

which should then hopefully come first
You can set it by doing

ccmake -DCMAKE_LIBRARY_PATH=/usr/lib/X11/ /path/tio/oofem/

Or if you use the CMake GUI then you can do "Add entry"

Note:

• You might need to remove the cache to make it forget about the old libs in /opt/

• If it insist on finding /opt/ libs first, then you could force it to ignore that path by using the CMAKE_IGNORE_PATH variable

• You also might need to add set CMAKE_INCLUDE_PATH as well

Short version;
I made a new CMakeLists.txt that you can try out.

Hmm. The only difference I can spot right now is the following libraries (which you had linked in the old version, and not with cmake);

-lm -lXmu -lXt

which weren't needed on linux. Did you still get the same error message with the new libs specified?

Could you just manually try out the following command
/usr/bin/g++   -g -DDEBUG -Wl,-search_paths_first -Wl,-headerpad_max_install_names   CMakeFiles/oofeg.dir/src/main/oofeg.C.o  -o oofeg  liboofem.a liboofem.a /Users/gustel/Elixir/src/libesi.a /Users/gustell/Elixir/src/libelixir.a /Users/gustel/Ckit/src/libckit.a /usr/X11/lib/libSM.dylib /usr/X11/lib/libICE.dylib /usr/X11/lib/libX11.dylib /usr/X11/lib/libXext.dylib /usr/X11/lib/libXaw.dylib /usr/X11/lib/libXmu.dylib  /usr/X11/lib/libXt.dylib -lm

And if that doesn't work, can you please paste the output from

file /lib/libXaw.dylib

and also the linker errors that you get

Yes, its easily done, I just didn't know I which ones I had to add by.

I have another new CMakeLists.txt for you to try out. I didn't explicitly add "-lm" since it should be included by default by the compiler (even without X11, the math lib is needed)

Sorry, I thought I had replied to it already.

I still need to switch shared libs to off and switch static libs on.
Also, when I configure with ccmake oofeg I get an output which reads

/opt/local/lib/libXmu.dylib/opt/local/lib/libXt.dylib

However, when I continue to generate, I am able to make oofeg.

Also, during the compilation, I get these warnings

In file included from /Users/gustel/Elixir/include/Econfig.h:43,
                 from /Users/gustel/Elixir/include/Etypes.h:42,
                 from /Users/gustel/Elixir/include/Esimple.h:70,
                 from /Users/gustel/oofem.git/src/oofemlib/oofeggraphiccontext.h:63,
                 from /Users/gustel/oofem.git/src/oofemlib/femcmpnn.h:58,
                 from /Users/gustel/oofem.git/src/oofemlib/element.h:38,
                 from /Users/gustel/oofem.git/src/fm/fmelement.h:38,
                 from /Users/gustel/oofem.git/src/fm/cbselement.h:38,
                 from /Users/gustel/oofem.git/src/fm/tr1_2d_cbs.h:38,
                 from /Users/gustel/oofem.git/src/fm/tr1_2d_cbs.C:35:
/Users/gustel/Elixir/include/Ecfg.h:133:1: warning: this is the location of the previous definition

Now that I know what to do, it is fine for me. However, maybe for other mac users the shared library issue might not be obvious?