MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0005865CMakeCMakepublic2007-10-11 06:182016-06-10 14:30
ReporterJosef Karthauser 
Assigned ToBill Hoffman 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005865: Windows cl compilations should explicitly use the correct linker.
DescriptionIn Platforms/Windows-cl.cmake the location of the 'link' binary is assumed to be in the path, whereas by that point the location of the compiler cl.exe has already been determined by absolute path. This means that it is possible at make/nmake time for the wrong linker to be used if the $ENV{PATH} is different from what it was at CMake time.

The linker should be assumed to be in the same location as the compiler, not assumed to be in the path.
Steps To Reproduce
Additional InformationIn some environments a number of different compilers are supported. For instance one might be using multiple cl.exe's - Microsoft ship a different one for XBox 360 builds for example, and so some developers have a Win32 cl.exe and an XBox360 cl.exe in different locations. With the proposed change it is possible to select one or the other, by setting the $ENV{PATH} to point to the correct compiler at CMake time (from within a CMakeLists.txt file for instance), and then the build becomes independent of the path at compile time.
TagsNo tags attached.
Relationships
Attached Filespatch Windows-cl.cmake.patch (1,776) 2007-10-11 06:18
https://public.kitware.com/Bug/file/1178/*
? Windows-cl.cmake.patch2 (1,926) 2007-10-12 09:12
https://public.kitware.com/Bug/file/1180/Windows-cl.cmake.patch2
Issue History
Date ModifiedUsernameFieldChange
2007-10-11 06:18Josef KarthauserNew Issue
2007-10-11 06:18Josef KarthauserFile Added: Windows-cl.cmake.patch
2007-10-12 09:10Josef KarthauserNote Added: 0009421
2007-10-12 09:11Josef KarthauserNote Deleted: 0009421
2007-10-12 09:12Josef KarthauserFile Added: Windows-cl.cmake.patch2
2007-10-12 09:13Josef KarthauserNote Added: 0009422
2007-10-14 18:26Alex NeundorfNote Added: 0009470
2007-10-14 18:26Alex NeundorfCategoryCCMake => CMake
2007-10-23 10:47Josef KarthauserNote Added: 0009532
2007-10-24 11:21Alex NeundorfNote Added: 0009546
2007-10-24 12:06Josef KarthauserNote Added: 0009548
2007-12-17 17:31Bill HoffmanStatusnew => assigned
2007-12-17 17:31Bill HoffmanAssigned To => Alex Neundorf
2008-01-02 12:59Alex NeundorfNote Added: 0010047
2008-01-02 12:59Alex NeundorfAssigned ToAlex Neundorf => Bill Hoffman
2008-01-02 14:08Bill HoffmanNote Added: 0010049
2008-01-07 17:35Alex NeundorfNote Added: 0010093
2008-01-07 17:36Alex NeundorfNote Added: 0010094
2016-06-10 14:27Kitware RobotNote Added: 0041393
2016-06-10 14:27Kitware RobotStatusassigned => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:30Kitware RobotStatusresolved => closed

Notes
(0009422)
Josef Karthauser   
2007-10-12 09:13   
I can't work out how to remove the old patch! I've uploaded a new one to fix a path handling bug. The new one is called patch2.
(0009470)
Alex Neundorf   
2007-10-14 18:26   
Is the patch against cmake 2.4.x or current cvs ?

Alex
(0009532)
Josef Karthauser   
2007-10-23 10:47   
It's against 2.4.7.
(0009546)
Alex Neundorf   
2007-10-24 11:21   
I'm not the expert with cl, but usually there is a batch file shipped with the compiler which sets up PATH and also some other variables for the compiler, like include and library paths.
With this patch the correct executables should be found, but isn't it still necessary to run the batch file in order to get the right include and library dirs ?

Alex
(0009548)
Josef Karthauser   
2007-10-24 12:06   
They can be set by hand, if necessary, from within a CMakeLists file.
However the linker cannot, instead it is hard coded, and assumed (unlike the compiler) that it is in the path. This is inconsistent behaviour.

So I propose either softening the assumption by assuming that the linker is in the same directory as the compiler, or allowing the location of the linker to be overridden. However the later is not preferable, as the compiler/linker locations are mostly derived before the CMakeLists.txt gets run.
(0010047)
Alex Neundorf   
2008-01-02 12:59   
I cannot work an that bug, I don't have any Windows installation on my private machines.

Beside that I would also think that it would be nice if it would be only required for the initial cmake run to set up the environment variables before.

Maybe when running cmake the first time, cmake could get these environment variables (PATH for the tools, INCLUDES and LIBRARIES and some more), try to evaluate/parse them and then store the values in the cache and use e.g. the INCLUDES one with INCLUDE_DIRECTORIES() ?

Alex
(0010049)
Bill Hoffman   
2008-01-02 14:08   
I do not think it is too much to ask that people have a working command line environment to start with. There is not a good way for cmake to set environment variables at build time since it is no longer running.
(0010093)
Alex Neundorf   
2008-01-07 17:35   
I think cmake doesn't actually have to set environment variables.
PATH: not necessary anymore once the executables have been found with the full path
INCLUDES (or what the name is): must be detected on the initial cmake run, the directories which have been added by the batch file need to be extracted and stored in the cache, and then these directories can be used with INCLUDE_DIRECTORIES(), e.g. in CMakeFiles/CMake[C CXX]Compiler.cmake added, so they will be used for every compiler execution.

LIBRARIES (I'm sure that's the wrong name): same as for the include dirs, LINK_DIRECTORIES() can be used here.

This could be done by getting the environment variables, then explicitely running the batch file, get the env.vars. again and then compare them.

Alex
(0010094)
Alex Neundorf   
2008-01-07 17:36   
There were one or two more env.vars. set in the batch file, maybe they are really necessary, maybe they are not, I don't know.

Alex
(0041393)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.