[begou]

I'm trying to compile OpenFoam 1.6 on linux openSuse 11.1 x86_64.
I get an error with the cmake command in PV3FoamReader with cmake trying
to use a directory which does not exist:

+ cmake ../..
CMake Error: The source directory "/hasources/pillonm/OpenFOAM/OpenFOAM-1.6/applications/utilities/postProcessing/graphics/PV3FoamReader/PV3FoamReader" does not exist.

my $HOME is /HA/sources/pillonm
it is a link to an autofs mount point:

ls -ld /HA/sources
/HA/sources -> /tmp_mnt/hasources/.

This config seams to make some trouble to cmake version 2.6-patch 1

Any idea ? I'm not familliar with cmake and I do not success in finding where this broken path is built in cmake config files (nothing in CMakeLists.txt in PV3FoamReader)

Thanks for your help

Patrick

[wyldckat]

Greetings Patrick,

Well that's very odd... did you copy-paste the actual text or did you type it here? Because if cmake actually gave:

CMake Error: The source directory "/hasources/pillonm/

and the real home directory is:

/HA/sources/pillonm/

then it really can be a bug on the cmake 2.6 patch 1 version... a very weird bug indeed...

Have you check if this folder exists:

$HOME/OpenFOAM/OpenFOAM-1.6/applications/utilities/postProcessing/graphics/PV3FoamReader/PV3FoamReader

If it does exist, try unpacking the file ThirdParty-1.6.linuxGcc.gtgz, so you'll get the pre-built version cmake 2.6 patch 4 that comes with binary package for 32 bit.
Start a new terminal or source again OpenFOAM's bashrc script.
Now (as you probably already know) run:

cmake -v

to check if the patch 4 version is up and running. If it is, try to compile once more the PV3FoamReader!
NOTE: if by any chance this cmake version won't run, you might need to install in OpenSUSE the package ia32libs for running 32bit executables in a x86_64 system.

By the way, did you successfully build Paraview with the current version of cmake that you have installed?

Best regards,
Bruno

[begou]

Originally Posted by wyldckat

Well that's very odd... did you copy-paste the actual text

yes, it's a copy/paste from the screen.

Originally Posted by wyldckat

Have you check if this folder exists:

$HOME/OpenFOAM/OpenFOAM-1.6/applications/utilities/postProcessing/graphics/PV3FoamReader/PV3FoamReader

Yes, I have it:

pillonm@thor: ls $HOME/OpenFOAM/OpenFOAM-1.6/applications/utilities/postProcessing/graphics/PV3FoamReader/PV3FoamReader
CMakeLists.txt Make PV3FoamReader.qrc PV3FoamReader_SM.xml PV3FoamReader.xml vtkPV3FoamReader.cxx vtkPV3FoamReader.h

Originally Posted by wyldckat

If it does exist, try unpacking the file ThirdParty-1.6.linuxGcc.gtgz, so you'll get the pre-built version cmake 2.6 patch 4 that comes with binary package for 32 bit.
Start a new terminal or source again OpenFOAM's bashrc script.
Now (as you probably already know) run:

cmake -v

to check if the patch 4 version is up and running. If it is, try to compile once more the PV3FoamReader!

There is no cmake in ThirdParty-1.6.


I think it is a cmake bug because:
1) I've downloaded cmake-2.8.1 sources
2) i've run ./bootstrap to build cmake 2.8.1 and it fails with a similar message:
CMake Error: Could not find cmake module file:/hasources/pillonm/OpenFOAM/cmake-2.8.1/CMakeFiles/CMakeCCompiler.cmake
3) I've check I can reproduce the probleme with and without loading OpenFoam environment.
4) I'v unpacked cmake-2.8.1 sources on a local partition (not a link to a NFS mount point) and on the same computer the bootstrap command and the build is successfull for cmake.
5) I've tried to compile again PV3FoamReader with this new cmake version
and I get the same error than with 2.6-patch 1.

I will try to put OpenFOAM sources on a local partition to build the binaries but has all users are on nfs mounted partitions with same configuration and some of them have to compile OpenFOAM....

[wyldckat]

Greetings Patrick,

Originally Posted by begou

There is no cmake in ThirdParty-1.6.

Uhm, this file ThirdParty-1.6.linuxGcc.gtgz (link included) is the 32bit binaries, that when unpacked at you OpenFOAM base folder, you should get the folder "ThirdParty-1.6/cmake-2.6.4/platforms/linux"! Don't confuse this package with the 64bit or source code packages!

Originally Posted by begou

I think it is a cmake bug because:
1) I've downloaded cmake-2.8.1 sources
2) i've run ./bootstrap to build cmake 2.8.1 and it fails with a similar message:
CMake Error: Could not find cmake module file:/hasources/pillonm/OpenFOAM/cmake-2.8.1/CMakeFiles/CMakeCCompiler.cmake

I've just done these 2 steps on a virtual machine (Ubuntu 9.04 32bit) with a mount to the host (Ubuntu 9.10 64bit), and did a symbolic link with "ln -s" from a folder to the other folder, ran bootstrap on the linked folder and it worked fine. Nonetheless, I didn't manage to get an NFS to work

My guess is that the actual problem isn't in cmake, but it is autofs that is giving a bad address to the files... for some weird reason...

OK, first test I would do is running bootstrap directly on the NFS folder mount ( /tmp_mnt/hasources/pillonm/OpenFOAM/cmake-2.8.1 ), thus removing the autofs interpretation layer. If it still crashes, then it should be the NFS layer who's to blame. But if it works, then move on to the next two possibilities:

1. make a symbolic link directly to the folder on "/tmp_mnt/hasources/" and try again from the linked area! Something like:

   ln -s /tmp_mnt/hasources/pillonm/OpenFOAM/cmake-2.8.1 $HOME/OpenFOAM/cmake_linked
   cd $HOME/OpenFOAM/cmake_linked
   ./bootstrap

   If it crashes on the same issue as before, then it should really be a problem from autofs Because the layer setting is " autofs->link->nfs ". If it doesn't crash, it's because the symbolic link made a secure connection... somehow... but autofs would still be the one to blame :P
2. if the previous test worked fine, also try making a symbolic link locally for the whole OpenFOAM folder, something like:
   

   cd $HOME
   mv OpenFOAM OpenFOAM_orig
   ln -s $HOME/OpenFOAM_orig $HOME/OpenFOAM

   Although this will slow down things a bit, it will give an additional file system layer that should be more compatible with whichever function cmake and bootstrap are using to access the file system, by providing a full linked path to be accessed.

Depending on your results from these tests, I could try and reproduce them with Ubuntu VM's to try to isolate if it's something only related to OpenSUSE's autofs/NFS implementation or something like that.

Best regards,
Bruno

[begou]

I'm back with the solution for this cmake problem !

It is not NFS nor autofs nor link related. The removing of the begining of my path is hardcoded in cmake .

In cmake-2.8.1/Source/kwsys/SystemTools.cxx file line 4646.

4645 // Work-around an SGI problem by always adding this mapping:
4646 SystemTools::AddTranslationPath("/tmp_mnt/", "/");

I'm not on SGI but my home directory is nfs automounted on: /tmp_mnt/hasources
Lack of chance. And ALL the computers of the team are using this Path to mount the home patition from a HA nfs server

Removing this line, cmake works fine. And Allwmake too.

[wyldckat]

Hello Patrick,

Wow, then you were right!

Originally Posted by begou

I think it is a cmake bug because:
...

Indeed a weird bug... and by the look of it, it seems to be an old fix too... an incomplete fix. You should consider posting this bug to the CMake bug report system... I think they use a mailing list for bug reports.

I'm glad you managed to solve the problem and thanks for posting the solution!!

Best regards,
Bruno