[cmake-developers] install bug on windows

Bill Hoffman bill.hoffman at kitware.com
Mon Sep 20 15:40:35 EDT 2010


On 9/20/2010 1:39 PM, Eric Noulard wrote:
> 2010/9/20 Eric Noulard<eric.noulard at gmail.com>:
>> 2010/9/20 Bill Hoffman<bill.hoffman at kitware.com>:
>>>
>>> Eric,
>>>
>>> This commit is breaking windows installs:
>>>
>>> commit 6a521f8604ee4e6a757109e731a36fdc5575f6c8
>>> Author: Eric NOULARD<eric.noulard at gmail.com>
>>> Date:   Mon Aug 23 17:38:33 2010 +0200
>>>
>>>     CPack   Enable better handling of absolute installed files
>>>
>>>     The idea of the patch is to let the install generator define
>>>     CPACK_ABSOLUTE_INSTALL_FILES then when CMake is installing
>>>     project he will concatenate the list of files and give
>>>     it to specific CPack Generator by defining CPACK_ABSOLUTE_INSTALL_FILES
>>>     to be the list of ALL files that were installed using absolute
>>> destination.
>>>     An example of use has been applied to RPM generator which now
>>>     tries to automatically build a relocatable package.
>>>
>
> [...]
>
>>> Why do you convert the / to an output path?
>>
>> I do not remember ... :-(
>>
>> I'm looking into this just now, give half an hour and I'll come
>> with some answer.
>
> Now I know: this is a plain mistake :-).
>
>>> 6a521f86 (Eric NOULARD       2010-08-23 17:38:33 +0200  71)    os<<  dest<<
>>> cmSystemTools::ConvertToOutputPath("/");
>>> 6a521f86 (Eric NOULARD       2010-08-23 17:38:33 +0200  72)    if (rename&&
>>> *rename)
>>>
>>> All paths in the cmake_install file should be cmake paths as cmake is going
>>> to consume them.
>>
>> Off course, you are right.
>
> Considering this is plain mistake, the fix is obvious
>
> os<<  dest<<  "/";
>
> corresponding patch is attached.
>
> Would you like me to apply it to next or would you
> prefer to do it yourself?
>
>>> All that said, I am not sure why no test failed from this ????
>>
>> May be because there is no test with absolutely installed file
>> in the test suite?
>>
>> I'll have a look too.
>
> OK I think I know.
> The provided example from Micha Renner is a little awkward
> it uses "unix-like" absolute install path "/usr/local"
> on a Windows hosts :-)
>
> May be it's supposed to work but I wonder if
> it's a common usage pattern.

The path he used does not really mater, it should have worked.
>
> The bare reality is twofold:
>
>    a) I do not use windows platform myself so I rely
>        on dashboard for regression.
>
>    b) I did not add a [cross platform] test for this change
>
> I shall try to write one test for this, but this may not be easy
> to write a cross-platform one because I'll have to find a "writable"
> "absolute destination" for each platform.
>
> On Unix platforms "/tmp" should be ok
> On WIndows I really don't know.
>
>   What do you think?
Use the absolute path to the binary directory for the project, it should 
always be writable.  The test should not try to write into system areas 
even if it can...

For example this change:
INSTALL(FILES ${CMAKE_SOURCE_DIR}/CTest.c
   DESTINATION ${T_BINARY_DIR}/usr/local)


Still gives the same error:

 >CMake Warning (dev) at cmake_install.cmake:31 (list):
1>  Syntax error in cmake code at
1>    C:/Users/hoffman/Max/tm/src/b/cmake_install.cmake:32
1>  when parsing string
1>    C:/Users/hoffman/Max/tm/src/b/usr/local\CTest.c
1>  Invalid escape sequence \C


So, if you could create a patch with a test that would be great.


-Bill



More information about the cmake-developers mailing list