Subject: Discussion related to cado-nfs
List archive
- From: Emmanuel Thomé <emmanuel.thome@gmail.com>
- To: Emmanuel Thomé <emmanuel.thome@gmail.com>
- Cc: "cado-nfs-discuss@lists.gforge.inria.fr" <cado-nfs-discuss@lists.gforge.inria.fr>
- Subject: Re: [Cado-nfs-discuss] Cmake does not respect path to gcc
- Date: Mon, 28 Jul 2014 14:23:09 +0200
- List-archive: <http://lists.gforge.inria.fr/pipermail/cado-nfs-discuss/>
- List-id: A discussion list for Cado-NFS <cado-nfs-discuss.lists.gforge.inria.fr>
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@gmail.com> wrote:
> Le 24 juil. 2014 19:39, "Andreas Enge" <andreas.enge@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@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/cado-nfs-discuss
- [Cado-nfs-discuss] Cmake does not respect path to gcc, Andreas Enge, 07/23/2014
- Re: [Cado-nfs-discuss] Cmake does not respect path to gcc, Emmanuel Thomé, 07/23/2014
- Re: [Cado-nfs-discuss] Cmake does not respect path to gcc, Andreas Enge, 07/24/2014
- Re: [Cado-nfs-discuss] Cmake does not respect path to gcc, Zimmermann Paul, 07/25/2014
- Re: [Cado-nfs-discuss] Cmake does not respect path to gcc, Emmanuel Thomé, 07/28/2014
- Re: [Cado-nfs-discuss] Cmake does not respect path to gcc, Emmanuel Thomé, 07/28/2014
Archive powered by MHonArc 2.6.19+.