[CMake] What's the point for making component-specific directory for CPack?

[Doug Gregor]

On Tue, Jul 29, 2008 at 4:44 AM, Yuri Timenkov <ytimenkov at parallels.com> wrote:
> On Monday 28 July 2008 22:04:57 Doug Gregor wrote:
>> On Mon, Jul 28, 2008 at 1:48 PM, Yuri Timenkov <ytimenkov at parallels.com>
> wrote:
>> > On Monday 28 July 2008 21:16:25 Doug Gregor wrote:
>> >> On Mon, Jul 28, 2008 at 12:45 PM, Yuri Timenkov
>> >> <ytimenkov at parallels.com>
>> >>
>> >> > I suppose for RPM there could be each top-level
>> >> > group - is a RPM archive which includes all components and subgroups.
>> >>
>> >> I'd suggest each top-level group and component, since components don't
>> >> have to be in groups.
>> >
>> > I meant in this context "groupless" components are top-level groups.
>>
>> Okay.
>>
>> >> > I want to make generating of rpm single-pass, that is one spec
>> >> > contains multiple %files sections. But rpm needs all files to be
>> >> > installed into single build directory. Moreover, one file can be in
>> >> > different packages and when several packages are generated from single
>> >> > spec, it's OK for rpm, but I'm not sure about different specs.
>> >>
>> >> Interesting. Are there other advantages to building multiple RPMs in a
>> >> single pass?
>> >
>> > packaging time, dependency tracking (if one file is in different rpms
>> > generated from one spec, they can be installed at the same time without
>> > conflict), timestamps, single debug package for multiple binary packages.
>>
>> Okay, I'm convinced :)
>>
>> >> It probably has to be a virtual function that decides whether
>> >> components need to be installed into separate directories or into a
>> >> single directory. When installing all of the components into a single
>> >> directory, you'll need a way to determine which files came from which
>> >> components. You could do that either by incrementally installing
>> >> components and walking the installed directory tree each time to see
>> >> what changed, or by finding and reading the manifests that CMake
>> >> writes when it installs a component.
>> >
>> > Yes, I was looking again to manifests... Why does CPack uses globs to
>> > determine file list?
>>
>> I don't know :)
>>
>> With INSTALL(DIRECTORY), we don't know what files will be installed
>> until after we've told CMake to do the installation, so we can either
>> look at what was installed or read the manifest. I wasn't around when
>> this decision was made for CPack.
>>
>> > I supposed it is good form to add custom actions to
>> > CMAKE_INSTALL_MANIFEST_FILES list.
>>
>> Probably, but that doesn't mean that people actually do this properly.
>> If we're going to start relying on manifests, we should probably also
>> add some code to produce a warning or error when a file not mentioned
>> in a manifest is installed; otherwise, we'll get a bunch of bug
>> reports along the lines of "my CPack installation used to work, but
>> now it's missing files!"
>>
>> So, I guess a virtual function bool
>> componentInstallsInSeparateDirectories(), for which the PackageMaker
>> and NSIS generators return "true" but the RPM generator returns false,
>> is what we'll need.
> This is really not needed, because tempInstallDirectory used only if
> SET_DESTDIR is OFF :) Otherwise, everything is installed into
> baseTempInstallDirectory. Also I noticed, that realInstallDirectory variable
> is not longer used, so you can have a troubles in projects which set forth
> parameter in CPACK_INSTALL_CMAKE_PROJECTS to something other than "/".
>
> So things with DESTDIR get really bad and too generator-dependent. What will
> happen if someone try to create RPM package without DESTDIR but with default
> /usr prefix? Will rpmbuild pack everything in my system (I didn't try :) ).

There's an open bug report about CPACK_DESTDIR always needing to be ON
for the RPM generator (and, perhaps, other generators), here:

  http://www.vtk.org/Bug/view.php?id=7000

Are there any generators for which both ON and OFF are both reasonable
settings for CPACK_DESTDIR?

  - Doug