View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0013490 | CMake | CPack | public | 2012-08-25 17:11 | 2012-10-14 08:44 | ||||
Reporter | sigma | ||||||||
Assigned To | Eric NOULARD | ||||||||
Priority | normal | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | x64 | OS | windows | OS Version | 7 | ||||
Product Version | CMake 2.8.9 | ||||||||
Target Version | CMake 2.8.10 | Fixed in Version | CMake 2.8.10 | ||||||
Summary | 0013490: CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION not honored | ||||||||
Description | When I set CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION to OFF this is not honored. I am basically trying to use it with CPack: SET(CPACK_INSTALL_COMMANDS "cmake -DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=OFF -DCPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION=OFF -P cmake_install.cmake") so as to overcome the very annoying fatal error: ... ABSOLUTE path INSTALL DESTINATION forbidden (by caller): ... Some of my install(FILES .. DESTINATION ... ) use absolute paths, but I am not even sure why installing files with an absolute path as the install destination would be a fatal error, if anything it should be a warning at most. cmake_install.cmake has checks for these variables, but they are always set to 1. Is there another way to set these variables to 0 (OFF) that works? Is there a way to convert absolute to relative paths? | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | build-logs-package-problem.zip [^] (214,206 bytes) 2012-08-26 09:51 | ||||||||
Relationships | |
Relationships |
Notes | |
(0030760) Eric NOULARD (developer) 2012-08-25 17:55 |
If you use CPack you should set(CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION OFF) or set(CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION 0) in your CMakeLists.txt or CPack project config file or on the cpack command line. CPack internally set CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION to 0/1 depending on the value of CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION. Moreover CPack force it to true as well whenever the CPack generator (i.e. TGZ, RPM, NSIS, ...) cannot handle absolute destination. Currently NSIS CPack generator is the only generator which does that, because absolute installed file just ** DO NOT WORK ** with NSIS and it has generated several bug report and/or question on the mailing list, this is the reason this feature has been added in 2.8.9. Before that you didn't get any error, but 100% of the time the built NSIS installer was buggy. On windows installing files using absolute path, i.e. something like: install(TARGET myExe "E:/My Program File/Blah") will install "myExe" on the host and you may be able to build an NSIS installer **BUT** "myExe" won't be included in the NSIS installer!! The idea is: NEVER EVER use absolute destination installation on Windows at best it won't work the way you think it work. now concerning: > Is there a way to convert absolute to relative paths? This is usually easy: install(TARGET myExe DESTINATION MySoftware) Attach or copy/paste the install rules from your CMakeLists.txt and I'll give you more precise advice. |
(0030761) Eric NOULARD (developer) 2012-08-25 17:58 |
Concerning > but I am not even sure why installing files with an absolute path as the > install destination would be a fatal error, > if anything it should be a warning at most. This is not an error for CMake (and you should be able to use the generated INSTALL target in the IDE you use) This is an error for CPack + NSIS on Windows for sure. |
(0030762) Eric NOULARD (developer) 2012-08-25 18:16 |
Some past references concerning ABSOLUTE destination and CPack and possible errors misunderstanding: http://www.cmake.org/pipermail/cmake/2008-August/023390.html [^] http://www.cmake.org/pipermail/cmake/2009-January/026724.html [^] http://www.cmake.org/pipermail/cmake/2010-January/034436.html [^] http://www.cmake.org/pipermail/cmake/2012-May/050263.html [^] this again justify the feature in order to ease the tracking of ABSOLUTE DESTINATION installed file. |
(0030763) Eric NOULARD (developer) 2012-08-25 18:18 |
Waiting for feedback. Mostly to answer this question Why do you need ABSOLUTE DESTINATION on Windows ? and may be: Did it work the way you expected with previous version of CMake/CPack? |
(0030764) sigma (reporter) 2012-08-25 20:35 |
I just wrote a detailed answer and the form rejected my input (some expired security token or whatever), telling me to go "Back", where obviously what I wrote was gone. I can't redo all of it, took me a good hour to compile, so I'll probably just highlight some points and add more details later. sorry, ack!! > Why do you need ABSOLUTE DESTINATION on Windows ? My build system is using the CMAKE_CURRENT_SOURCE_DIR to create new directories, copy around files and pre-create the package directory structure. So it is an absolute path. > Did it work the way you expected with previous version of CMake/CPack? Yes, I just tested with 2.8.5 and the .zip file is generated without issues. If I switch to 2.8.9 without changing anything, then I get the above mentioned errors. this shouldn't be. I have to take a closer look, but this: > set(CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION OFF) > or > set(CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION 0) isn't working, i just tried. It just resets to 1 for whatever reason. Which makes it pretty hard to understand if it's my fault or not. According to what you say there are probably some cases that may reset this without notice... > On windows installing files using absolute path, i.e. something like: > install(TARGET myExe "E:/My Program File/Blah") this in my opinion is a perfectly valid way to setup an install target. No reason why CPack should care about this. This step is for cmake to install. maybe i have misunderstood the cpack functionality and limitations, so please bear with me. |
(0030765) Eric NOULARD (developer) 2012-08-26 03:03 |
> I just wrote a detailed answer and the form rejected my input (some expired > security token or whatever), telling me to go "Back", ... I get caught by this occasionally, now I type my long comment in an editor and copy/paste it to Mantis to avoid loosing it. I ask for help on cmake developer ML for that, may be that can be fixed on Mantis installation side. >> Did it work the way you expected with previous version of CMake/CPack? >Yes, I just tested with 2.8.5 and the .zip file is generated without issues. You mean you do: cpack -G ZIP and you don't get the ZIP file? Could you do capture the log of CPack run when it fails? ZIP generator should not error out in such case. With 2.8.5, are you sure all what you want to install is in the ZIP file? Are you using the produce ZIP file to install your software on another machine or do you simply call INSTALL target for installing on the development host? By the way which CMake generator do you use some Visual Studio one? Do you set CPACK_SET_DESTDIR to ON? May be you can attach your CPackConfig.cmake file to the tracker? >> Why do you need ABSOLUTE DESTINATION on Windows ? > My build system is using the CMAKE_CURRENT_SOURCE_DIR to create new > directories, copy around files and pre-create the package directory > structure. Fine. > So it is an absolute path. You don't need absolute path to do what you want, but it's not easy to explain that in your particular case without concrete example. Can you craft a small example project that exhibit the issue? >> set(CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION 0) > isn't working, i just tried. I cannot imagine how it couldn't work (from source code and my own test), so I must be missing something. I think our best way to investigate the issue would be to build a small example. Could you do that? Create a small example project that exhibit the issue? If you can do that attach it to the tracker and then I can try to reproduce the issue. |
(0030766) sigma (reporter) 2012-08-26 09:51 |
> You mean you do: > cpack -G ZIP and you don't get the ZIP file? no I use INCLUDE(CPack) and "nmake package" > Could you do capture the log of CPack run when it fails? > ZIP generator should not error out in such case. > With 2.8.5, are you sure all what you want to install is in the ZIP file? yes everything is there, I double checked. > Are you using the produce ZIP file to install your software on another > machine or do you simply call INSTALL target for installing on the development > host? no, I don't want to install from the zip. I basically (as you probably figured) use it with buildbot to upload a zip on a webpage via buildbot. > By the way which CMake generator do you use some Visual Studio one? I use NMake Makefiles JOM and I build from command line. > Do you set CPACK_SET_DESTDIR to ON? no >> So it is an absolute path. > > You don't need absolute path to do what you want, but it's not > easy to explain that in your particular case without concrete > example. the build process is quite complex and there are other reasons I use absolute paths. I do not however disagree it is possible an all-relative-paths rework could be done, but I'd rather not since previous cmake worked just fine and I don't see it being justified to enforce relative paths for the ZIP generator. > Can you craft a small example project that exhibit the issue? I know it's a holy grail for testing, but that's tough, I can try and replicate it, but that implies I know what causes the problem and target it. Currently, I don't understand which configuration option is causing the problem, and taking apart my whole build system is just not feasible at least in a time efficient manner. I am attaching you instead two sets of logs, one for each of the 2.8.5 and 2.8.9 cmake versions, so you can compare what happens. In there you will find two logs, one that shows you what my build process tells me (most of it is custom output, so bear with me) regarding the process and the error, and the respective CPackConfig.cmake >>> set(CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION 0) >> isn't working, i just tried. > > I cannot imagine how it couldn't work (from source code and my own test), > so I must be missing something. > > I think our best way to investigate the issue would be to build > a small example. > > Could you do that? > Create a small example project that exhibit the issue? > If you can do that attach it to the tracker and then I can try > to reproduce the issue. I know it's very difficult to fix such a problem without a minimal example. I will try and take some time and do that once I understand where the problem is. If you want have a look at the files I attached and if we still don't get anywhere then I'll try see if it is easy to replicate somehow. |
(0030767) sigma (reporter) 2012-08-26 09:54 |
i kept the two builds from 2.8.5 and 2.8.9 as they occurred, so if the files i attached are not enough let me know, I have the whole build/ folder for each version archived. |
(0030768) Eric NOULARD (developer) 2012-08-26 16:40 edited on: 2012-08-26 16:42 |
OK, If you purge your build tree and try to do what you do WITHOUT setting any of CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION **not even to OFF** Do NOT do it at ALL, neither in the CMakeLists.txt nor on the command line as you currently do. With this those var shall not appear anywhere, NOT in CMakeCache.txt and NOT in CPackConfig.cmake. With that does cpack -G ZIP generate the same error? The ZIP generator must not warn aboit anything if those variables are NOT set to anything. If you have any error/warning could you add: variable_watch(CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION) variable_watch(CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION) in your CMakeLists.txt. By the way WHY do you set "CPACK_INSTALLED_DIRECTORIES" and why? |
(0030769) sigma (reporter) 2012-08-26 18:42 |
I removed all instances of using CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION CMAKE_WARN_ON_ABSOLUTE_INSTALL_DESTINATION and it now seems to work as expected with 2.8.9. I also tried the cpack command and it also works. Indeed you're right, there are no warnings whatsoever. > By the way WHY do you set "CPACK_INSTALLED_DIRECTORIES" and why? I don't really remember why I added this in there. What you see in the attached files are generated from a combination of variables, and I suspect it may be useful when I package multiple sub-projects into one .zip and may not make sense for this simpler case .. unfortunately I don't remember. I also wouldn't claim to know CMake and CPack thoroughly, so some things may not be useful or odd. Anyway, do you think this is expectable behavior or it would be useful to change it to allow people to set these ON/OFF? btw, thanks for your help, it's greatly appreciated. |
(0030770) Eric NOULARD (developer) 2012-08-27 03:25 |
Ok, now I understand the behavior. > do you think this is expectable behavior or it would > be useful to change it to allow people to set these ON/OFF Yes and the "real" bug is that C*_ON_ABSOLUTE_INSTALL_DESTINATION is not checked for its value but whether if it is set or not set. This is a bug and I'll fix it. However, as you now verified not setting any of those variables should not trigger any error/warning, but for NSIS for which it has NEVER work to install with an absolute destination. So, at least, there is no behavior "regression". Concerning the usefulness of your "CPACK_INSTALLED_DIRECTORIES" usage I cannot guess without more knowledge of your CMake build system. This var is meant to "install" the content of a directory specified as a list of pair. The first argument of a pair specifies the directory to be installed and the second argument relative path where to graft this directory inside the package (most of the time it's "."). You have: SET(CPACK_INSTALLED_DIRECTORIES "D:/buildbot/qbookie-windows-x64-cylencio/build/dist/qbookie/;.") The strange part is that you should already have all what you need because you have: SET(CPACK_INSTALL_CMAKE_PROJECTS "D:/buildbot/qbookie-windows-x64-cylencio/build/build;qbookie;ALL;/") SET(CPACK_INSTALL_PREFIX "D:/buildbot/qbookie-windows-x64-cylencio/build/dist/qbookie") The trouble I have with your usage is that cpack is supposed to do its packaging work in a private directory and not clutter the host file system with file because of the packaging. What I mean is that, when you something like: install(FILE blah.txt DESTINATION "C:/Program Files/bin") when you do $ make package (or cpack -G ZIP) not only the file goes into the ZIP but **it is intalled** into "C:/Program Files/bin" before that. This is not what most people expect. When you want to install you do! $ make install and when you want to package you do: $ make package the later shall not imply the former. |
(0030772) sigma (reporter) 2012-08-27 05:00 |
Thanks for looking into this and the upcoming fix. I will take a second on look on my build system for sure, i appreciate your comments. > when you do > $ make package (or cpack -G ZIP) > > not only the file goes into the ZIP but **it is intalled** into > "C:/Program Files/bin" before that. this is actually what I want to do, when i package I want the build system to invoke an installation. Most likely this is an odd way to create a dependency between these steps, but I remember that it solves other problems with files not being generated/updated if you forget to install, before packaging (effectively packaging an older version of the files, etc). anyway, thanks again for the help! |
(0031228) Eric NOULARD (developer) 2012-10-14 08:44 |
I've just checked-in a clean fix. Merge topic 'Fix-XXX_ON_ABSOLUTE_INSTALL_DESTINATION-handling' into next 561b4ba CPACK_XX_ON_ABSOLUTE_INSTALL_DESTINATION is now properly checked for ON/OFF |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2012-08-25 17:11 | sigma | New Issue | |
2012-08-25 17:38 | Eric NOULARD | Assigned To | => Eric NOULARD |
2012-08-25 17:38 | Eric NOULARD | Status | new => assigned |
2012-08-25 17:55 | Eric NOULARD | Note Added: 0030760 | |
2012-08-25 17:58 | Eric NOULARD | Note Added: 0030761 | |
2012-08-25 18:16 | Eric NOULARD | Note Added: 0030762 | |
2012-08-25 18:18 | Eric NOULARD | Note Added: 0030763 | |
2012-08-25 18:18 | Eric NOULARD | Status | assigned => feedback |
2012-08-25 20:35 | sigma | Note Added: 0030764 | |
2012-08-25 20:35 | sigma | Status | feedback => assigned |
2012-08-26 03:03 | Eric NOULARD | Note Added: 0030765 | |
2012-08-26 09:51 | sigma | Note Added: 0030766 | |
2012-08-26 09:51 | sigma | File Added: build-logs-package-problem.zip | |
2012-08-26 09:54 | sigma | Note Added: 0030767 | |
2012-08-26 16:40 | Eric NOULARD | Note Added: 0030768 | |
2012-08-26 16:42 | Eric NOULARD | Note Edited: 0030768 | |
2012-08-26 18:42 | sigma | Note Added: 0030769 | |
2012-08-27 02:49 | Eric NOULARD | Target Version | => CMake 2.8.10 |
2012-08-27 03:25 | Eric NOULARD | Note Added: 0030770 | |
2012-08-27 05:00 | sigma | Note Added: 0030772 | |
2012-10-14 08:44 | Eric NOULARD | Note Added: 0031228 | |
2012-10-14 08:44 | Eric NOULARD | Status | assigned => closed |
2012-10-14 08:44 | Eric NOULARD | Resolution | open => fixed |
2012-10-14 08:44 | Eric NOULARD | Fixed in Version | => CMake 2.8.10 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |