(0009422)
Josef Karthauser (reporter)
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 (developer)
2007-10-14 18:26

Is the patch against cmake 2.4.x or current cvs ?

Alex

(0009532)
Josef Karthauser (reporter)
2007-10-23 10:47

It's against 2.4.7.

(0009546)
Alex Neundorf (developer)
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 (reporter)
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 (developer)
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 (manager)
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 (developer)
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 (developer)
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 (administrator)
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.

Issue History
Date Modified	Username	Field	Change
2007-10-11 06:18	Josef Karthauser	New Issue
2007-10-11 06:18	Josef Karthauser	File Added: Windows-cl.cmake.patch
2007-10-12 09:10	Josef Karthauser	Note Added: 0009421
2007-10-12 09:11	Josef Karthauser	Note Deleted: 0009421
2007-10-12 09:12	Josef Karthauser	File Added: Windows-cl.cmake.patch2
2007-10-12 09:13	Josef Karthauser	Note Added: 0009422
2007-10-14 18:26	Alex Neundorf	Note Added: 0009470
2007-10-14 18:26	Alex Neundorf	Category	CCMake => CMake
2007-10-23 10:47	Josef Karthauser	Note Added: 0009532
2007-10-24 11:21	Alex Neundorf	Note Added: 0009546
2007-10-24 12:06	Josef Karthauser	Note Added: 0009548
2007-12-17 17:31	Bill Hoffman	Status	new => assigned
2007-12-17 17:31	Bill Hoffman	Assigned To	=> Alex Neundorf
2008-01-02 12:59	Alex Neundorf	Note Added: 0010047
2008-01-02 12:59	Alex Neundorf	Assigned To	Alex Neundorf => Bill Hoffman
2008-01-02 14:08	Bill Hoffman	Note Added: 0010049
2008-01-07 17:35	Alex Neundorf	Note Added: 0010093
2008-01-07 17:36	Alex Neundorf	Note Added: 0010094
2016-06-10 14:27	Kitware Robot	Note Added: 0041393
2016-06-10 14:27	Kitware Robot	Status	assigned => resolved
2016-06-10 14:27	Kitware Robot	Resolution	open => moved
2016-06-10 14:30	Kitware Robot	Status	resolved => closed

Notes
(0009422) Josef Karthauser (reporter) 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 (developer) 2007-10-14 18:26	Is the patch against cmake 2.4.x or current cvs ? Alex

(0009532) Josef Karthauser (reporter) 2007-10-23 10:47	It's against 2.4.7.

(0009546) Alex Neundorf (developer) 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 (reporter) 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 (developer) 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 (manager) 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 (developer) 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 (developer) 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 (administrator) 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.

Relationships