On Fri, Sep 1, 2017 at 1:40 PM, Alex Turbov <i.za...@gmail.com> wrote: > Hi Robert, > > > On Fri, Sep 1, 2017 at 9:21 PM, Robert Dailey <rcdailey.li...@gmail.com> > wrote: >> >> >> One problem I thought of with the former (one big target.cmake with >> all import targets in there) is that if you only ask for a subset of >> components in find_package(), you will still get all of them since all >> imports are defined in a single file. > > > In my project I have a bunch of components and do one exported target per > component > exactly by the mentioned reason -- user didn't ask for others... > >> >> Does this go against any design >> principles? > > > As far as I know, there are no clear design principles :) (yet, at least > nowadays) -- at least doing > a lot of CMake projects since 2009, I've never seen an explicit list of them > %) > IMHO, there is a lack of "official guildelines" (or it is really hard to > search for 'em) > >> Assuming this really happens, are there any negative side >> effects? > > > I could see the impact on build time only in this case... and for me the > most obvious is increasing > time to process the lists (which is for some reasons really slow on Windows, > at least in our > build farm which uses vargant and VirtualBox images) > (but I don't have any particular numbers, cuz never implemented the first > approach)
Thanks for the quick response. The "official guidelines" or "package standard" is really exactly what we need I think. What worries me the most is that it seems like this is deep knowledge that is stuck in the brains of folks like Brad King and David Cole. I think somehow getting a knowledge dump from them into a documentation page would be a valuable task. I think for something as complex and variable as packages in CMake (install process in general) deserves some standardization, because we need the ability to distinguish between practices that we should follow for legacy (backward compatibility) reasons, non-cmake project reasons, and fully "modern" cmake packages. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
