Re: [cmake-developers] Need ideas/opinions on third party library management
ld libraries in real time along with our project. So the order of > > operations would be as follows (for our automated build server): > > > > 1. Clone our "Third Party" repository > > 2. Use CMake to generate & build the "Super Build" project (this > > builds boost, openssl, freetype, etc for the current platform). > > 3. Clone the main code base's repository > > 4. Use CMake to generate & build, using find_package() to refer to > > interface targets exported by those third party libraries built in > > step 2 > > > > Obviously this will make builds take significantly longer, because > > we're constantly rebuilding the same third party libraries over and > > over again. However, it virtually eliminates the maintenance burden > > for third party libraries because they are built inherently with > > everything else. > > > > Note that I can't refer to pre-built libraries in our build > > environments because we need very specific control over the versions > > of our libraries as well as the toolchains that were used to build > > them. Also we may specifically build our libraries a certain way (such > > as boost). For this reason we do not rely on our external environment > > or external package managers to fulfill third party dependencies, like > > most open source projects do on Linux for example. > > > > Does this "Super Build" approach sound like a better idea? What other > > options are available? The downside with the "Super Build" solution is > > that it will become very difficult to make the transition between > > building third party and building our code base seamless. I can't do > > both in the same generate step because find_package() can't be called > > until the libraries are built & installed. > > -- > > > > 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-developers > > -- > > 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-developers > -- *Benjamin BALLET* Ingénieur R *ACTIVISU* 19, rue Klock - 92110 Clichy *> Standard Tél* : 01 44 69 37 37 *>* www.activisu.com -- 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-developers
[cmake-developers] patch bugfix : CMAKE_VS_PLATFORM_TOOLSET not defined for VisualStudio 2010
Hi, I stumbled on a bug : CMAKE_VS_PLATFORM_TOOLSET is empty when generating for VisualStudio 2010 Here is a patch -- *Benjamin BALLET* Ingénieur R *ACTIVISU* 19, rue Klock - 92110 Clichy *> Standard Tél* : 01 44 69 37 37 *>* www.activisu.com 0001-VS-set-DefaultPlatformToolset-to-v100-for-VisualStud.patch Description: Binary data -- 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-developers
[cmake-developers] patch VS2010 generator : handle VS_GLOBAL_RootNamespace as well as VS_GLOBAL_ROOTNAMESPACE
Hi folks, As user I'm currently working on migrating C++CLI projects to CMake. I wasted a few hours because I used VS_GLOBAL_RootNamespace (a specialized version of VS_GLOBAL_ property) instead of VS_GLOBAL_ROOTNAMESPACE. So here is a patch to save the next one from wasting those same hours. In my opinion, VS_GLOBAL_ROOTNAMESPACE with VS_GLOBAL_PROJECT_TYPE and VS_GLOBAL_KEYWORD should be tagged as deprecated and users should be redirected to VS_GLOBAL_. It would be simpler. -- *Benjamin BALLET* Ingénieur R *ACTIVISU* 19, rue Klock - 92110 Clichy *> Standard Tél* : 01 44 69 37 37 *>* www.activisu.com 0001-VisualStudio10-generator-the-RootNamespace-property-.patch Description: Binary data -- 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-developers
Re: [cmake-developers] patch for module GetPrerequisites
We have to call :
fixup_bundle("${CMAKE_INSTALL_PREFIX}/../test"...
to fix an optional test folder installed near the app.
verify_app will later compare a path like C:/program/app/../test to
C:/program/test and state they are inequal while they point to the same
file.
That's why I have to call get_filename_component(path "${path}" REALPATH)
just to force the convertion from C:/program/app/../test to C:/program/test
Thanks, hope I clearified
2016-03-07 19:07 GMT+01:00 Brad King <brad.k...@kitware.com>:
> On 03/04/2016 12:17 PM, Benjamin Ballet wrote:
> > The fail occurs during verify_app in the function gp_resolved_file_type
> > from module GetPrerequisites. This function test if two paths are equal
> > without translating them to there canonical form before.
> [snip]
> >get_filename_component(original_path "${original_lower}" PATH)
> >get_filename_component(path "${lower}" PATH)
> > + get_filename_component(original_path "${original_path}" REALPATH)
> > + get_filename_component(path "${path}" REALPATH)
>
> This is operating on a string(TOLOWER)-converted path already.
> On case-sensitive filesystems it does not make sense to call
> REALPATH for these. The code is doing string manipulation of
> the paths at this point.
>
> Please explain the case you're hitting in more detail. How
> does one end up with a non-canonical path in the first place?
>
> Thanks,
> -Brad
>
>
--
*Benjamin BALLET*
Ingénieur R
*ACTIVISU*
19, rue Klock - 92110 Clichy
*> Standard Tél* : 01 44 69 37 37
*>* www.activisu.com
--
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-developers
[cmake-developers] patch for module GetPrerequisites
Hello We are using fixup_bundle on Windows and I discovered that this function doesn't work if the path of the app is not in it's canonical form. Of course I can canonicalize the path of the app but I would like to fix this issue for everyone. The fail occurs during verify_app in the function gp_resolved_file_type from module GetPrerequisites. This function test if two paths are equal without translating them to there canonical form before. Here is the patch for this modification -- *Benjamin BALLET* Ingénieur R *ACTIVISU* 19, rue Klock - 92110 Clichy *> Standard Tél* : 01 44 69 37 37 *>* www.activisu.com 0001-GetPrerequisites-function-gp_resolved_file_type-shou.patch Description: Binary data -- 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-developers
