No subject

...which clued me into the CPACK_SET_DESTDIR=ON setting.

It seems like there is some blurriness when it comes to delineating the 
roles of various CMake variables as to whether they control behavior
of "make install" vs. "make package" (or both, as seems to be the case
here)  I'm no expert, so I could be missing things, but I think the 
behavior should be:

CMAKE_INSTALL_PREFIX - controls "make install", does NOT effect "make package"

CPACK_PACKAGING_INSTALL_PREFIX - controls "make package", has no effect on "make install"

Thanks,

   -Chris


On 8/6/10 8:18 PM, Chris Wolf wrote:
> 
> 
> On 8/6/10 6:30 PM, David Cole wrote:
>> On Fri, Aug 6, 2010 at 5:49 PM, Chris Wolf <cw10025 at gmail.com> wrote:
>>
>>> I'm still unclear what you're suggesting here (quote, below).  If
>>> I run "make package", doesn't that make target invoke cpack with the
>>> cmake-generated cpack options file (CPackConfig.cmake)?
>>>
>>> ...and isn't "cpack --config CPackConfig.cmake" equivalent?
>>>
>>> Also, nowhere in the ./share/cmake-2.8.2/Modules directory do a see
>>> files named "CMakeCPack.cmake" and "CMakeCPackOptions.cmake.in", that
>>> you refer me to.
>>>
>>> Could you be suggesting I download the source code of cmake and dig through
>>> that?
>>>
>>
>> Yes. Those files are used to prepare the packaging of CMake itself, and it
>> is a great example of the stuff you gotta do to have a packager that works
>> everywhere.
>>
>>
> 
> Sorry, I looked at "CMakeCPack.cmake" and "CMakeCPackOptions.cmake.in"
> and it still seems that it should be
> CPACK_PACKAGING_INSTALL_PREFIX that sets this, but changing this
> variable has no effect.
> 
> Looking at the source code, (now the C++ code), I see this function
> 
> cmCPackPackageMakerGenerator::InitializeInternal() calls:
> this->SetOptionIfNotSet("CPACK_PACKAGING_INSTALL_PREFIX", "/usr");
> 
> ...which even further reinforces the idea that that is the variable
> that's causing the issue.
> 
> All I want to do is not have the package contents prefixed by "./usr/"
> and there doesn't seem any way to stop that.
> 
> I guess I'll have to build CMake/CPack from scratch and run
> CPack in a debugger and step through cmCPackGenerator::DoPackage()
> to find out how this is handled! LOL...
> 
> Unless anyone else has an idea?
> 
> 
>>
>>
>>>
>>> Thanks,
>>>
>>>  -Chris
>>>
>>>
>>> On 8/6/10 4:52 PM, David Cole wrote:
>>>> You need a CPackOptions file (CPACK_PROJECT_CONFIG_FILE) that gets loaded
>>> at
>>>> CPack time.....
>>>>
>>>> In CMake, ours has this at the bottom of it:
>>>>
>>>> if("${CPACK_GENERATOR}" STREQUAL "PackageMaker")
>>>>   if(CMAKE_PACKAGE_QTGUI)
>>>>     set(CPACK_PACKAGE_DEFAULT_LOCATION "/Applications")
>>>>   else(CMAKE_PACKAGE_QTGUI)
>>>>     set(CPACK_PACKAGE_DEFAULT_LOCATION "/usr")
>>>>   endif(CMAKE_PACKAGE_QTGUI)
>>>> endif("${CPACK_GENERATOR}" STREQUAL "PackageMaker")
>>>>
>>>> To use one, set one up (either hand written or configured), something
>>> like
>>>> this:
>>>>   CONFIGURE_FILE("${CMake_SOURCE_DIR}/CMakeCPackOptions.cmake.in"
>>>>     "${CMake_BINARY_DIR}/CMakeCPackOptions.cmake" @ONLY)
>>>>   SET(CPACK_PROJECT_CONFIG_FILE
>>>> "${CMake_BINARY_DIR}/CMakeCPackOptions.cmake")
>>>>
>>>>
>>>> See CMake's "CMakeCPack.cmake" and "CMakeCPackOptions.cmake.in" files in
>>> the
>>>> top level directory for more CPack magic than you'll be able to absorb on
>>> a
>>>> Friday afternoon.... :-)
>>>>
>>>>
>>>> HTH,
>>>> David
>>>>
>>>>
>>>> On Fri, Aug 6, 2010 at 4:45 PM, Chris Wolf <cw10025 at gmail.com> wrote:
>>>>
>>>>> Earlier, I identified a problem with the "PackageMaker" (Apple)
>>> packager,
>>>>> and now, I see the same exact problem with the "DEB" (Debian)
>>>>> packager - it keeps prefixing "./usr" to all the paths.
>>>>>
>>>>> Changing CPACK_PACKAGING_INSTALL_PREFIX doesn't do anything
>>>>> (even when it's at the top of the file)
>>>>>
>>>>> This problem does not occur with packagers of type "DragNDrop",
>>>>> "TGZ" and "TBZ2" - these are Ok.
>>>>>
>>>>> Any help would be great, thanks...
>>>>>
>>>>>  -Chris
>>>>>
>>>>>> Another observation regarding the CPack-generated *.pkg
>>>>>>>> (wrapped in a *.dmg) :
>>>>>>>>
>>>>>>>> The path is prefixed by "./usr", somehow:
>>>>>>>>
>>>>>>>> (assuming the *.dmg is already mounted)
>>>>>>>> $ cd ./libusb-0.1.1-Darwin.pkg/Contents
>>>>>>>> $ lsbom -s Archive.bom
>>>>>>>> .
>>>>>>>> ./usr
>>>>>>>> ./usr/lib
>>>>>>>> ./usr/lib/libusb.dylib
>>>>>>>>
>>>>>>>> So where does the "./usr/" prefix come from?
>>>>>>
>>>>>> I'm do not know the dmg CPack Generator
>>>>>> (is it PackageMaker or DragNDrop?)
>>>>>>  and I'm not a mac user but each CPack generator has a default
>>>>>> "builtin" CPACK_PACKAGING_INSTALL_PREFIX.
>>>>>>
>>>>>> Try
>>>>>> set(CPACK_PACKAGING_INSTALL_PREFIX. "/whatever")
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>
>>