On Tue, Jul 29, 2008 at 4:44 AM, Yuri Timenkov <[EMAIL PROTECTED]> wrote: > 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 :) ).
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 _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
