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

[Yuri Timenkov]

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 :) ).

>
>   - Doug