David Cole wrote:
The drag-n-drop generator puts a copy of the "make install" tree at the
root of the disk image produced...
So if your "make install" tree has bundles in it, they're in there.
Otherwise, not.
So if I have a shared file that needs to end-up in bundle foo, I'd have
to use something along the lines of "foo.app/Content/Resources" as the
DESTINATION. Makes sense.
I think the answer to your question : "will '..' always work in INSTALL
rules?" is -- it depends. We will not knowingly break it
intentionally... However, unless there is a test for it in the cmake
test suite, it may get broken unintentionally.
Could you devise/contribute a new test (or an extension to an existing
test) that would verify that the INSTALL behavior we have now remains
that way?
I will definitely write / extend a test for this case.
On the other hand, I can think of some cases where you will have
file/dir create/write access under the CMAKE_INSTALL_PREFIX directly,
but not in some of its subdirectories. In that case, it would not work
even now...
Understood. Thanks for clarifying these issues.
Cheers,
Tim
--
Timothy M. Shead
Data Analysis & Visualization (1424)
Sandia National Laboratories
505-284-0139
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
