[Cado-nfs-discuss] Cmake does not respect path to gcc

Emmanuel Thomé emmanuel.thome at gmail.com
Mon Jul 28 14:23:09 CEST 2014


Sorry for the bogus e-mail sent previously.

Our problem here is that we're not using very idiomatic cmake
parameter handling. A knowledgeable cmake user will certainly be
surprised by how we react on environment variables. Someone who knows
nothing about cmake, on the other hand, will be surprised by the fact
that changes to local.sh (or env variables in general) don't
immediately carry over to the build dir unless one does "make cmake"
or "make tidy".

There's probably some janitor work needed for re-thinking which
variables should be flagged as "CACHE" in cmake sense. It's not
something very entertaining to do. The current situation is messy, to
say the least.

E.

On Mon, Jul 28, 2014 at 2:18 PM, Emmanuel Thomé
<emmanuel.thome at gmail.com> wrote:
> Le 24 juil. 2014 19:39, "Andreas Enge" <andreas.enge at inria.fr> a écrit :
>
>> Exporting $CC and $CXX works, assuming that one first deletes the build
>> directory where test results are cached. Being used to the autotools,
>> this is a bit surprising, and I needed the help of a cmake-savvy colleague
>> to figure this out. How about creating a separate script ./configure
>> that deletes the build directory and makes the cmake call to configure
>> the project, and let make handle only the build process?
>>
>> Maybe the behaviour I reported is not a bug after all. I had the debian
>> cc, gcc and g++ in /usr/bin, and the guix gcc and g++ (no cc) in $PATH.
>> The configure step then used the cc in /usr/bin. So apparently cc is
>> checked before gcc, which is different from the autotools, but looks
>> like acceptable behaviour after all.
>>
>> Concerning gmp, it is also in a separate directory, which is referenced
>> by $CPATH and $LIBRARY_PATH. I can pass it via $GMP, but it would be nice
>> if the check for gmp honoured these environment variables. (Well, all
>> these problems for the user would disappear by using the autotools...)
>>
>> Currently, configuration fails with
>> CMake Error at config/python.cmake:9 (message):
>>   Python interpreter not found
>> Call Stack (most recent call first):
>>   CMakeLists.txt:142 (include)
>>
>> This is at least a misleading error message: I have python-2.7 as
>> /usr/bin/python. Looking at config/python.cmake, it appears I need
>> python-3.
>>
>> Andreas
>>
>> _______________________________________________
>> Cado-nfs-discuss mailing list
>> Cado-nfs-discuss at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/cado-nfs-discuss


More information about the Cado-nfs-discuss mailing list