2012/3/13 Schwartz, Philip Marc (RIS-BCT) <philip.schwa...@lexisnexis.com>: > I am close to completing the patch file, but have run into one issue that I > am having trouble locating a where I am going wrong. > > The condition is when you have installs that fall under 'Unspecified' but the > CPACK_COMPONENT_NONAME_FOR is defined as an existing component. > > The current issue is when I have a defined CPACK_COMPONENT_NONAME_FOR I want > to disable packaging of 'Unspecified'.
No you shouldn't 'disable' it. The variable CPACK_COMPONENTS_ALL gives you the list of component to be installed (which defaults to all component including "Undefined" if the user did not specified CPACK_COMPONENTS_ALL) If CPACK_COMPONENT_NONAME_FOR may contain the name of the unique component for which no name mangling is done. We cannot authorize more than one component (including Undefined) to have this property set because it would break the uniqueness property of package file names. > I have looked in the looping calls to GetComponent() in > InstallProjectViaInstallCMakeProjects() and cannot determine the correct way > of removing 'Unspecified' from packaging. > > It appears as if the function controls which components should be installed, > but adding code to remove or prevent 'Unspecified' from being installed does > not appear to stop the component from being packaged. > > Where is the component actually being added to the map<> Components and what > is the best way to remove it? I'll look into that but like I said you shouldn't remove component this way, you should stick to the content of CPACK_COMPONENTS_ALL. Concerning the CPACK_COMPONENT_NONAME_FOR, this is a separate feature that should consists in a second patch set. It's really better to avoid to implement several features and/or bug fixe in a single patch/commit. Submit the first part of your modifications for package file name template + test for it, then you can work on a second patch set build on top of this first one that implement the CPACK_COMPONENT_NONAME_FOR feature. As a sidenote, be prepared to may be not have your patch not accepted "as-is" on the first shot so it's better for you and the reviewer (most probably me) to have possibly small and incremental patch set. It is then easier to handle the review and the loop for converging to an acceptable patch. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
