Re: [cmake-developers] Preferred variable retrieval within Cpack generator.
2012/3/13 Schwartz, Philip Marc (RIS-BCT) : > 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
Re: [cmake-developers] Preferred variable retrieval within Cpack generator.
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'. 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? -- 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
Re: [cmake-developers] Preferred variable retrieval within Cpack generator.
2012/3/12 Schwartz, Philip Marc (RIS-BCT) : > >>Usually using GetOption means that we want to give user some control so that >>this CPACK_xxx value may be set in >CMakeLists.txt, CPack project config file >>or CPack command line arg. > >>GetOption is not used to pass value from cmCPackGenerator class to its >>daughter classes. > > It is looking like this will be the preferred option as I want to be able to > define this for all classes that inherit from cmCPackGenerator allowing the > variables to be set for all generators that might use them. The important question is would this option be settable by user in the CMake script? If yes then you soud use GetOption. >>If the feature "may" be shared by all generators then it ought to be defined >>in the cmCPackGenerator base class. >>(let's call it generic CPack generator) >>If some data are processed by the generic CPack generator and then used by >>some daughter classes then you can add a protected field member. > >>This is the case for cmCPackGenerator::Components, or even >>cmCPackGenerator::files. > > I don't think I am creating anything that will require this. The focus is > around changing how the name is handled, not adding further variables in the > generator to the mix. Ok. >>I'm not sure I did catch all the implication of "I am allowing the package >>specific generator to build a map of >the parameters for naming and pass the >>map into the function GetComponentPackageFileName" > > Be for deciding on using GetOption to allow the variables to be set by a > cmake file directly in the cmCPackGenerator class, I was doing this work in > the subclass for the type specific generator and creating a > std::map that contained a value map. This was a bad > way of doing it and reason for the first email and after reading the email > has been changed. > > I go on vacation on Friday and I am out for a week. I am hoping to have the > first version of the patch out in the bug before then. OK then. I'll go answer on the tracker as well. -- 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
[cmake-developers] Preferred variable retrieval within Cpack generator.
What is the preferred method of variable retrieval and/pr parameter passing in the cpack generator structure. I have seen a mixture of passing values into functions and also using GetOption to obtain the wanted value. I am currently looking at adding new functionality to allow for better control of package naming when working with generation of packages. This will include using a variable template for creation of the naming schema to be used. Currently I am allowing the package specific generator to build a map of the parameters for naming and pass the map into the function GetComponentPackageFileName. This will allow for the specific generator to control the values, but I am not sure if it is more efficient to use GetOption directly in the function. What are the thoughts of the other developers working on CMake and CPack? Thank You, Philip Schwartz Senior Software Engineer LexisNexis RIAG O - 561 999 4472 C - 954 290 4024 - The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -- 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
