View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013490CMakeCPackpublic2012-08-25 17:112012-10-14 08:44
Reportersigma 
Assigned ToEric NOULARD 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Platformx64OSwindowsOS Version7
Product VersionCMake 2.8.9 
Target VersionCMake 2.8.10Fixed in VersionCMake 2.8.10 
Summary0013490: CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION not honored
DescriptionWhen 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?
TagsNo tags attached.
Attached Fileszip file icon build-logs-package-problem.zip [^] (214,206 bytes) 2012-08-26 09:51

 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

 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


Copyright © 2000 - 2018 MantisBT Team