Craig, Thanks for the info. I went back and read through your post, and our build has many of the same issues you are facing. For our project I ended up keeping all dependencies in the context of the project workspace, and am not using the find* modules to fulfill dependencies.
Thomas Taranowski | 425-442-9209 | skype: thomas.taranowski | baringforge.com On Mon, Aug 26, 2013 at 4:14 PM, Craig Scott <[email protected]> wrote: > Thomas, there are a lot of parallels between your scenario and the one I > just posted a question about yesterday (see subject line "One build, > multiple compilers and packages"). One of the two scenarios that Matthew > suggested is the one we've used to handle the external third party > dependencies - we use ExternaProject for that. Matthew's comment that your > main project then needs to be an ExternalProject as well is only partially > correct though. If your main project(s) use find_library(), find_program(), > etc. to work out where the external third party targets get built, then you > would need to somehow ensure that the external project(s) is fully built > when the main project undergoes its configure step. Making your main > project an external project as well would accomplish this, but we found > that making everything into a set of external projects was less than ideal > (I'll save the details for that other thread if people want more info). > Rather than using find_XXX() for the external third part bits, since you > know where they will be in the build tree, you can instead use that > knowledge and construct the necessary variables directly at configure time > (which Matthew also suggested). This won't require the targets to have been > built yet, but it does mean you will then have to handle any platform > differences, etc. yourself (eg different library or executable prefixes and > suffixes). > > > > On Tue, Aug 27, 2013 at 7:36 AM, Matthew Woehlke < > [email protected]> wrote: > >> On 2013-08-26 16:37, Thomas Taranowski wrote: >> >>> I tend to agree with you that 2 would not generally be a target. >>> However, >>> there are external factors at play that I haven't mentioned. For one, in >>> our environment we'd like to pull the auto generated code into a code >>> review tool, and to mechanize that we have a commit daemon running that >>> can >>> run the auto generate rule, and commit the difference to a review-only >>> branch for inspection purposes. It's true that it could be accomplished >>> by >>> doing the all build, and grabbing the output after the build was >>> complete, >>> it just takes alot longer. >>> >> >> In that case, you could always add another custom target that depends on >> all of your generated output files (as well as the targets using the same >> depending on them), similar to a 'build all third party' target. >> >> >> -- >> Matthew >> >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/**CMake_FAQ<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<http://cmake.org/cmake/help/support.html> >> CMake Consulting: >> http://cmake.org/cmake/help/**consulting.html<http://cmake.org/cmake/help/consulting.html> >> CMake Training Courses: >> http://cmake.org/cmake/help/**training.html<http://cmake.org/cmake/help/training.html> >> >> Visit other Kitware open-source projects at http://www.kitware.com/** >> opensource/opensource.html<http://www.kitware.com/opensource/opensource.html> >> >> Follow this link to subscribe/unsubscribe: >> http://www.cmake.org/mailman/**listinfo/cmake<http://www.cmake.org/mailman/listinfo/cmake> >> > > > > -- > Craig Scott > Melbourne, Australia > > -- > > 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://www.cmake.org/mailman/listinfo/cmake >
-- 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://www.cmake.org/mailman/listinfo/cmake
