On Monday 28 July 2008 22:04:57 Doug Gregor wrote: > On Mon, Jul 28, 2008 at 1:48 PM, Yuri Timenkov <[EMAIL PROTECTED]> wrote: > > On Monday 28 July 2008 21:16:25 Doug Gregor wrote: > >> On Mon, Jul 28, 2008 at 12:45 PM, Yuri Timenkov > >> <[EMAIL PROTECTED]> > >> > >> > 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 _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
