[CMake] ccmake gets all squirrelly over which C++ compiler to use.

kent williams nkwmailinglists at gmail.com
Tue Mar 3 10:20:22 EST 2009


That's all well and good, but is exactly the sort of thing I DONT want
to have to put in FOSS CMakeaLists.txt files.  It would be useful in
situations like this where you're liking against multiple
system-installed CMake-built libraries.  But any other situation,
you'd run into problems where a naive user would download something,
configure it and then have the build fail with obscure linker errors
they're unqualified to diagnose and correct.

But that's beside the point of my post, which maybe I didn't make
clear: What was driving me nuts was the way that when CCMake finds an
error in your configuration, IT FORGETS WHAT YOU JUST LABORIOUSLY
TYPED IN THAT WAS IN FACT CORRECT.  Then you have to TYPE IT IN AGAIN.
 Then for some reason EVEN THOUGH YOU'VE ENTERED THE CORRECT CONFIG
INFORMATION, it throws a warning, and FORGETS WHAT YOU JUST TYPED IN
AGAIN.

Lather, Rinse, Repeat. After 2 or 3 go-arounds, CCMake is happy and
lets you generate your build files.

And if I recall correctly, earlier versions (2.3? 2.4?) did not act this way.

On Tue, Mar 3, 2009 at 4:27 AM, Mathieu Malaterre
<mathieu.malaterre at gmail.com> wrote:
> I have had this issue an infinite number of time. Debian packager
> would be using inconsistant c++ compiler and I could not use both ITK
> and VTK at the same time (from debian package). So I provided an
> (undocumented) hack:
> CMAKE_OVERRIDE_COMPILER_MISMATCH
>
> 2cts
>
> On Mon, Mar 2, 2009 at 8:27 PM, kent williams <nkwmailinglists at gmail.com> wrote:
>> Version 2.6 patch 2 on OS X and Linux -- you know your code is
>> portable when the same issue happens on multiple platforms!
>>
>> Here's the scenario -- a guy in our department was having trouble
>> getting ccmake to generate makefiles.
>>
>> My diagnosis was pretty simple: His project depended on both ITK and
>> VTK. ITK had been compiled with and VTK had been compiled with
>> '/usr/bin/g++'.  So he got into an infinite loop where CMake would
>> force the CMAKE_CXX_COMPILER to '/usr/bin/c++' when it processed
>> UseITK.cmake, then when it processed UseVTK.cmake, it woud force it
>> back to '/usr/bin/g++'.  Then it would tell you it had to delete
>> CMakeCache.txt, and re-run the Configuration pass.
>>
>> This turns the CCMake run into effectively an endless loop with a
>> human in the loop, endlessly trying to reconfigure.
>>
>> The solution was obvious -- make sure both VTK and ITK use the same
>> compiler Of course on most machines /usr/bin/c++ is a symbolic link to
>> /usr/bin/g++ (or vice versa) but CCMake can't assume that's the
>> case...
>>
>> But here is the real problem, the 'squirrelyness' referred to in the
>> subject line:
>>
>> In ccmake, once VTK and ITK were built with the same compiler, I
>> changed CMAKE_CXX_COMPILER to match what VTK and ITK were reporting,
>> set ITK_DIR and VTK_DIR , and hit compile.
>>
>> But again it would pop up a warning, and when I exited the warning
>> screen, CCMake had forgotten what I'd entered for CMAKE_CXX_COMPILER,
>> ITK_DIR, and VTK_DIR, so I had to type them in a second time.  Once I
>> did that, the Configure pass would finish and I could get through the
>> Generate pass.
>>
>> This is one specific case, but I've noticed in general that if the
>> Configure pass has an error, it forgets everything you just entered
>> and you have to re-enter it, and fix the error, and Configure again.
>> This is extremely frustrating, like dying in a video game and having
>> to go back and re-run all levels to get back to where you died.
>>
>> What's the story? Can this be fixed?
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
>>
>
>
>
> --
> Mathieu
>


More information about the CMake mailing list