Re: [CMake] Qt 5, macOS, bundle install

[Jean-Christophe Fillion-Robin]

Hi Romain,

> How can I add this simple example inside the CMake example/tutorial?

I suggest to add them to the cmake community wiki.
See https://gitlab.kitware.com/cmake/community/wikis/home

Jc

On Tue, Oct 9, 2018 at 11:27 AM Romain LEGUAY 
wrote:

> I found the solution!!
>
> I just add the plugins attached to the Qt Component (in my case
> Qt5Widgets) and install it:
>
> set(qtplugins)
> foreach(plugin ${Qt5Widgets_PLUGINS})
> get_target_property(_loc ${plugin} LOCATION)
> list(APPEND qtplugins ${_loc})
> endforeach()
>
> install_qt5_executable("${exe}" "${qtplugins}" "" "${dirs}" "")
>
> I found a part of the solution in the Qt documentation (
> http://doc.qt.io/qt-5/cmake-manual.html#imported-targets).
>
> How can I add this simple example inside the CMake example/tutorial?
>
> Romain
> --
>
> 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:
> https://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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] ExternalProject, BundleUtilities, CPack, and RPath management

[Jean-Christophe Fillion-Robin]

Hi Clifford,

You could have a look at the Slicer build system, see
https://github.com/Slicer/Slicer. It is based on ExternalProject.

* It makes use of CPACK_INSTALL_CMAKE_PROJECTS


* It uses BundleUtilities only on macos but the caveat of BundleUtilties is
that it is very very slow for large projects (indeed it traverses the full
set of dependencies for each plugin, apps, ...). At kitware, we internally
discussed implementing a C++ based version of bundle utilities but this is
not yet available.

There are many more details.

If you have specific questions, you could join the Slicer developer hangout
that take place every Tuesday at 10am EST. It is announced on discourse.
See https://discourse.slicer.org/c/community/hangout

Hth
Jc


On Sat, Oct 13, 2018 at 5:05 PM Clifford Yapp  wrote:

> I am contemplating attempting to use ExternalProject_Add and
> fixup_bundle to improve the long term maintainability of a large
> software product, but there are some implications that are potentially
> involved and I'd like to ask if anyone in the CMake community can
> offer insight.  The design constraints to satisfy (that are satisfied
> by our current "build everything wth CMake" approach):
>
> 1.  We need to be able to install our bundled dependencies seamlessly
> with the rest of the project when doing either a "make install" or
> "make package" - from the standpoint of the main software project, the
> external projects' outputs are handled exactly as if they were created
> by the "main" build (right now that's because they *are* part of the
> main build, but it's a property we want to preserve regardless.)
>
> 2.  Our "build" directory is laid out such that it mimics the
> installed layout (including any external dependencies we will be
> bundling) and CMake's RPath management settings are defined such that
> the build directory is fully functional without requiring any
> installation steps, LD_LIBRARY_PATH fiddling, or other user
> intervention.  Except for the presence of the ancillary files from
> configuration and building, structurally the build directory could be
> an install directory.
>
> 3.  At no point in the configure, build, or package creation process
> should it be necessary to place anything in the final
> CMAKE_INSTALL_PREFIX install location - someone without access to the
> CMAKE_INSTALL_PREFIX directory should still be able to create a
> proper, working package.
>
> 4.  Works seamlessly across Windows+MSVC, Linux, MacOSX and the BSDs.
> (In years past this was a challenge with ExternalProject_Add and
> Windows - trying to mix an nmake external build with an MSVC parent
> build on Windows didn't work, if I recall correctly.  Hopefully things
> are better nowadays...)
>
> Right now we are achieving these goals by creating CMake build files
> for all projects we need to manage as bundled dependencies, but
> writing those build systems when they don't already exist is a lot of
> work and doesn't scale long term (for example, not even I am crazy
> enough to want to write and maintain a separate CMake build for all of
> Qt).  I would like to be able to define an "external dependencies"
> repository with a build system which simply encodes the necessary
> rules to trigger the native build logic from the projects in question,
> builds a "deps_install" directory that the primary project's CMake
> build can be pointed to for build purposes, and then use the primary
> project's RPath settings from then on to manage the deps_install
> executable and library files as if they were outputs from build
> targets in the primary project.
>
> It feels like some combination of CPack, ExternalProject and
> BundleUtilties should be able to make this work as long as the
> deps_install binaries have RPaths defined that are suitable for
> manipulation by CMake, but unless I'm missing something (hopefully I
> am) this looks like a sufficiently obscure corner of the CMake toolbox
> that there isn't a lot to be found documenting the nitty-gritty of how
> to do it.  Can anyone direct me to a tutorial or a project that
> demonstrates how to make the combination of
> ExternalProject_Add+BundleUtilities+CPack work in a cross platform
> manner?
>
> Thanks,
> CY
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please kee

Re: [CMake] Putting the git commit hash in a cmake variable

[Ryan Pavlik]

Fwiw, this is my single most popular stack overflow post (and presumably my
most popular CMake module)
https://stackoverflow.com/questions/1435953/how-can-i-pass-git-sha1-to-compiler-as-definition-using-cmake/4318642#4318642

It does incorporate the other ideas that have come up, like making a
dependency on a git data file.

Ryan

On Fri, Oct 12, 2018, 10:33 AM Ben Boeckel  wrote:

> Sorry if this shows up oddly on the list; I was forwarded the original
> in order to reply. As such, please keep me in Cc.
>
> > I'd like to set a CMake variable to the current git commit short hash.
> > This variable will be used as part of the version string for my
> > project (ex: "1.0.1+git.${SHORT_HASH}"). I can get at this short hash
> > by using execute_process and setting the resulting output to a
> > variable.
> >
> > ```cmake
> > execute_process(
> > COMMAND
> > git rev-parse --short HEAD
> > RESULT_VARIABLE
> > SHORT_HASH_RESULT
> > OUTPUT_VARIABLE
> > SHORT_HASH)
> > ```
> >
> > My issue is that cmake will only run execute_process once, during the
> > configure step. I need cmake to run this execute_process on every
> > build and, if the output has changed, reconfigure to make sure
> > SHORT_HASH is up to date.
> >
> > I came up with one solution to this issue: During the configure step,
> > I can write the current short hash to a file named short_hash.txt. On
> > every build, I'll re-compute the short hash and verify that the
> > computed short hash is the same as what is in short_hash.txt. If its
> > not, I'll write the new short hash to short_hash.txt. I then make
> > short_hash.txt an input to configure_file. This will cause cmake to
> > validate SHORT_HASH is properly set, and re-configure if its not.
>
> I solved this a few years ago :) . Here are all the relevant files:
>
>
> https://github.com/Kitware/sprokit/blob/master/src/sprokit/version.h.in
>
> https://github.com/Kitware/sprokit/blob/master/src/sprokit/.gitattributes
>
> https://github.com/Kitware/sprokit/blob/master/src/sprokit/CMakeLists.txt
>
> https://github.com/Kitware/sprokit/blob/master/conf/sprokit-macro-configure.cmake
>
> Basically the solution follows:
>
>   - If we're in an archive (.gitattributes' export-subst), use the
> information from it. Detect this in CMake by checking if Git
> replaced substitutions for us:
>
> if ("$Format:$" STREQUAL "")
>
> If we are, just use that information (gathered using other
> `$Format:$` expansions).
>   - If not, we set up some code to run at build time to extract the
> information.
>   - The variables (or code) from above is injected via
> `sprokit_configure_file_always` which basically is just a
> `configure_file` done at build time. The list of variables to export
> to the script are listed as arguments. The `_always` bit just adds
> an extra output file named `${output}.noexist` which causes tools to
> always run the associated custom command (which is then attached to
> a custom target via its output file).
>
> The file is only updated if the contents change (via `configure_file`),
> so rebuilding should be minimal.
>
> --Ben
> --
>
> 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:
> https://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:
https://cmake.org/mailman/listinfo/cmake