[CCPPETMR/SIRF-SuperBuild] sets the PYTHONPATH to the install directory (#53)

[Edoardo Pasca]

Closes #52

---

You can view, comment on, or merge this pull request online at:

  https://github.com/CCPPETMR/SIRF-SuperBuild/pull/53

Commit Summary

• sets the PYTHONPATH to the install directory

File Changes

• M SuperBuild/External_SIRF.cmake (2)

Patch Links:

• https://github.com/CCPPETMR/SIRF-SuperBuild/pull/53.patch
• https://github.com/CCPPETMR/SIRF-SuperBuild/pull/53.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[evgueni-ovtchinnikov]

@evgueni-ovtchinnikov requested changes on this pull request.

This does not set PYTHONPATH, does it? So far as I can see, it is set in install/bin/env/ccppetmr.sh.

[Edoardo Pasca]

Indeed you are right, the title of the PR is wrong, it should read "sets the PYTHON_DEST to the install directory". (Fixed it now)

To resume:

1. The PYTHONPATH is set correctly in the env_ccppetmr.sh
2. The SIRF installation installed the python modules in the build/INSTALL directory which is wrong.
3. The proposed PR sets the installation of the python modules in the directory pointed by PYTHONPATH

[evgueni-ovtchinnikov]

I checked out pythonpath_fix on my VM, but make still builds in SIRF-SuperBuild/INSTALL. Probably the wrong setting still sits in the cache, but I do not remember which file I should delete to empty the cache.
By the way, I printed the value of CCPPETMR_INSTALL and it was empty, whereas SIRF_Install_Dir/python was the same as PYTHONPATH - but changing back from CCPPETMR_INSTALL to SIRF_Install_Dir had no effect.

[Kris Thielemans]

hi. I don't understand this at all.

a few lines above there's

set(SIRF_Install_Dir ${SUPERBUILD_INSTALL_DIR})

the latter is set in SuperBuild.cmake as

set (SUPERBUILD_INSTALL_DIR ${CMAKE_INSTALL_PREFIX})

so, the original code looks correct to me.

Indeed, on my VM, the Python files sit in devel/install/Python as they should be. I don't think I did anything special after downloading the 0.9.2 VM to fix that.

I suspect that you are confused by cached variables. PYTHON_DEST is cached, so once set, will keep its value. This is a bit annoying if you change the install location afterwards. The only way to solve that is by making it a non-cached variable. But that means people can't point it somewhere else.

You can delete a cached variable in cmake-gui or ccmake or using the -U option to cmake (or edit CMakeCache.txt but that's obviously dangerous).

[evgueni-ovtchinnikov]

I added two messages before and after setting PYTHON_DEST in External_SIRF.cmake:

message("PYTHON_DEST to be set to ${SIRF_Install_Dir}/python")
set(PYTHON_DEST "${SIRF_Install_Dir}/python" CACHE PATH "Destination for python modules")
message("PYTHON_DEST: ${PYTHON_DEST}")

Configuring in ccmake produced:

PYTHON_DEST to be set to /home/sirfuser/devel/install/python

PYTHON_DEST:

Any idea why?

From: Kris Thielemans [mailto:notifi...@github.com]
Sent: 31 October 2017 17:43
To: CCPPETMR/SIRF-SuperBuild
Cc: Ovtchinnikov, Evgueni (STFC,RAL,SC); Review requested
Subject: Re: [CCPPETMR/SIRF-SuperBuild] sets the PYTHON_DEST to the install directory (#53)


hi. I don't understand this at all.

a few lines above there's

set(SIRF_Install_Dir ${SUPERBUILD_INSTALL_DIR})

the latter is set in SuperBuild.cmake as

set (SUPERBUILD_INSTALL_DIR ${CMAKE_INSTALL_PREFIX})

so, the original code looks correct to me.

Indeed, on my VM, the Python files sit in devel/install/Python as they should be. I don't think I did anything special after downloading the 0.9.2 VM to fix that.

I suspect that you are confused by cached variables. PYTHON_DEST is cached, so once set, will keep its value. This is a bit annoying if you change the install location afterwards. The only way to solve that is by making it a non-cached variable. But that means people can't point it somewhere else.

You can delete a cached variable in cmake-gui or ccmake or using the -U option to cmake (or edit CMakeCache.txt but that's obviously dangerous).

—

You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub<https://github.com/CCPPETMR/SIRF-SuperBuild/pull/53#issuecomment-340844157>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AOWfVAcdHNsAvkaMHG5O7XJnmY_uXdCmks5sx1wOgaJpZM4QMaiK>.

[Kris Thielemans]

2 possible explanations:

• your cached variable is set to the empty string (doing a set on cached variable only works once)
• there are 2 occurences of PYTHON_DEST. In CMake, if you use a variable first (or of course, if you set it without CACHED), it creates a non-cached variable. If you then afterwards create a cached variable of the same name, you have 2 different variables around! they'll have 2 different values, and will be used in different contexts. (crazy, I know).

[evgueni-ovtchinnikov]

Thanks!

I deleted PYTHON_DEST in ccmake and it fixed the problem!

From: Kris Thielemans [mailto:notifi...@github.com]
Sent: 01 November 2017 10:13
To: CCPPETMR/SIRF-SuperBuild
Cc: Ovtchinnikov, Evgueni (STFC,RAL,SC); Review requested
Subject: Re: [CCPPETMR/SIRF-SuperBuild] sets the PYTHON_DEST to the install directory (#53)

2 possible explanations:

* your cached variable is set to the empty string (doing a set on cached variable only works once)
* there are 2 occurences of PYTHON_DEST. In CMake, if you use a variable first (or of course, if you set it without CACHED), it creates a non-cached variable. If you then afterwards create a cached variable of the same name, you have 2 different variables around! they'll have 2 different values, and will be used in different contexts. (crazy, I know).

—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub<https://github.com/CCPPETMR/SIRF-SuperBuild/pull/53#issuecomment-341062495>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AOWfVFMhPBBYzXrn3-orx0dvvK7NRdhUks5syERFgaJpZM4QMaiK>.

[Kris Thielemans]

@paskino I think we should close this (without merging)?

[Edoardo Pasca]

Closed #53.

[Edoardo Pasca]

Irrelevant, as it is a CMake cache problem.