1. 19 Jun, 2019 1 commit
  2. 17 Jun, 2019 2 commits
  3. 08 Apr, 2019 1 commit
  4. 08 Jan, 2019 1 commit
    • Tim Blechmann's avatar
      BundleUtilities: Ensure target dir exists when creating symlinks · 200bf577
      Tim Blechmann authored
      Commit v3.13.0-rc1~279^2 (GetPrerequisites: Move dylibs from MacOS
      to Frameworks folder in bundle, 2018-07-22) introduced a regression
      that can cause symlink creation to fail during packaging. Symlinks
      can be created before targets are installed, so the destination
      directory of the symlink sometimes won't exist at symlink creation.
      
      Fixes: #18726
      200bf577
  5. 30 Dec, 2018 1 commit
  6. 12 Nov, 2018 1 commit
  7. 19 Oct, 2018 1 commit
    • Kyle Edwards's avatar
      DeployQt4: Do not include BundleUtilities at configure time · 15bbff05
      Kyle Edwards authored
      Due to CMP0080, BundleUtilities can no longer be included at
      configure-time. However, DeployQt4 contains some functions which
      are meant to be used at configure-time, and some which are meant
      to be used at install-time and use BundleUtilities. This change
      breaks the file into two sections: common functions and install-time
      functions. BundleUtilities is now only included at install-time,
      thus fixing the policy warning.
      
      Fixes: #18466
      15bbff05
  8. 18 Oct, 2018 1 commit
  9. 10 Oct, 2018 1 commit
    • Kyle Edwards's avatar
      cmake_policy: Add undocumented GET_WARNING command · 0d988f98
      Kyle Edwards authored
      This command is intended for modules that issue policy warnings so
      they can get the warning string from CMake in a uniform manner,
      rather than duplicating the string. Several modules been updated
      to include an example of the usage of this new command.
      0d988f98
  10. 19 Sep, 2018 3 commits
  11. 20 Jul, 2018 1 commit
  12. 10 Mar, 2017 2 commits
  13. 10 Jan, 2017 1 commit
  14. 27 Sep, 2016 1 commit
    • Brad King's avatar
      Simplify CMake per-source license notices · 86578ecc
      Brad King authored
      Per-source copyright/license notice headers that spell out copyright holder
      names and years are hard to maintain and often out-of-date or plain wrong.
      Precise contributor information is already maintained automatically by the
      version control tool.  Ultimately it is the receiver of a file who is
      responsible for determining its licensing status, and per-source notices are
      merely a convenience.  Therefore it is simpler and more accurate for
      each source to have a generic notice of the license name and references to
      more detailed information on copyright holders and full license terms.
      
      Our `Copyright.txt` file now contains a list of Contributors whose names
      appeared source-level copyright notices.  It also references version control
      history for more precise information.  Therefore we no longer need to spell
      out the list of Contributors in each source file notice.
      
      Replace CMake per-source copyright/license notice headers with a short
      description of the license and links to `Copyright.txt` and online information
      available from "https://cmake.org/licensing".  The online URL also handles
      cases of modules being copied out of our source into other projects, so we
      can drop our notices about replacing links with full license text.
      
      Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
      of the replacements mechanically.  Manually fix up shebang lines and trailing
      newlines in a few files.  Manually update the notices in a few files that the
      script does not handle.
      86578ecc
  15. 19 Apr, 2016 1 commit
  16. 07 Mar, 2016 1 commit
  17. 11 Feb, 2016 1 commit
    • Christian Askeland's avatar
      BundleUtilities: Fix treatment of .dylib inside .framework folders · e422f738
      Christian Askeland authored
      The specific cause is when e.g.
      
          /Library/Frameworks/GStreamer.framework/Versions/1.0/lib/libgio-2.0.0.dylib
      
      is detected by fixup_bundle.  set_bundle_key_values() interprets this as
      a framework, thus doing a string replace that creates an embedded_item
      that is equal to the original path, i.e. it is not embedded.
      e422f738
  18. 17 Dec, 2015 1 commit
  19. 27 Feb, 2015 1 commit
  20. 10 Feb, 2015 1 commit
  21. 21 Oct, 2014 1 commit
  22. 10 Oct, 2014 3 commits
  23. 07 Aug, 2014 2 commits
  24. 14 Apr, 2014 2 commits
  25. 15 Oct, 2013 1 commit
  26. 23 Oct, 2012 1 commit
    • David Cole's avatar
      BundleUtilities: Use a more inclusive REGEX for frameworks (#13600) · 89256e03
      David Cole authored
      Some frameworks might be built with the library right at the root
      of the framework rather than down in a versioned sub-folder with
      a symlink at the root.
      
      Make one of the slashes in the REGEX optional so BundleUtilities
      can still properly work with such frameworks ... even if they are
      weird. ;-)
      
      Thanks to Tobias Hieta for the bug report and for trying out the fix
      before I pushed this commit.
      89256e03
  27. 13 Aug, 2012 1 commit
    • Kitware Robot's avatar
      Remove CMake-language block-end command arguments · 9db31162
      Kitware Robot authored
      Ancient versions of CMake required else(), endif(), and similar block
      termination commands to have arguments matching the command starting the
      block.  This is no longer the preferred style.
      
      Run the following shell code:
      
      for c in else endif endforeach endfunction endmacro endwhile; do
          echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
      done >convert.sed &&
      git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
      egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
      egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
      xargs -0 sed -i -f convert.sed &&
      rm convert.sed
      9db31162
  28. 02 Jun, 2011 1 commit
    • David Cole's avatar
      BundleUtilities: Avoid a cryptic and unhelpful error message · 8f0667c1
      David Cole authored
      When the path to "resolved_embedded_item" was shorter than
      the path to the bundle being fixed up, fixup_bundle would
      fail with a cmake error like:
      
        "string end index: 110 is out of range 0 - 85"
      
      Detect when the path of resolved_embedded_item is too short
      to be embedded in the bundle, and report the proper error
      message, so the poor developer reading it has a snowball's
      chance of actually fixing the issue.
      8f0667c1
  29. 27 May, 2011 1 commit
    • Clinton Stimpson's avatar
      BundleUtilities: Work w/ non .app exes on Mac (#12034) · 7ac7b437
      Clinton Stimpson authored
      Also add a test of BundleUtilities including an exe,
      some shared libs, a plugin, and a framework-style lib.
      
      This test presently runs (and this functionality works)
      on Linux, Mac and Windows.
      
      For now, the framework-style lib is built as a plain old
      shared lib because there is another yet-unresolved issue
      with local frameworks without rpaths on the Mac.
      7ac7b437
  30. 06 Dec, 2010 1 commit
    • David Cole's avatar
      BundleUtilities: error if fixup_bundle_item called on non-embedded item · c2895f48
      David Cole authored
      Also, improve the documentation of the fixup_bundle and fixup_bundle_item
      functions to clarify that plugin type "libs" need to be copied into
      the bundle *before* calling fixup_bundle.
      
      Commit e93a4b4d changed the way that
      the libs parameter to fixup_bundle is interpreted. Before the commit,
      the libs were copied into the bundle first and then fixed up. After
      the commit, the copy was skipped, assuming the libs were in the bundle
      in the first place, and then the fixups occurred as before.
      
      However, before the commit, it was possible to name a lib from outside
      the bundle, and have it copied in and then fixed up. Its resolved
      embedded name was always inside the bundle before. After, its resolved
      embedded name was just the same as its resolved name, which is in its
      original location, and not necessarily inside the bundle.
      
      This manifested itself as a problem with the ParaView call to
      fixup_bundle and its many plugins. Previously, ParaView had simply
      passed in the list of plugin file names as they existed in the build
      tree, and left the copying into the bundle up to the fixup_bundle
      function. When built with CMake 2.8.3 (the first version to contain
      the above named commit) the fixup_bundle call would inadventently
      fixup libraries in the build tree, not libraries that were in the
      bundle. Furthermore, the plugins would not be in the final bundle.
      
      This points out the fact that the fix for the bugs made by the above
      commit was a backwards-incompatible change in behavior.
      
      This commit makes it an error to try to fixup an item that is not
      already inside the bundle to make the change in behavior apparent
      to folks who were depending on the prior copy-in behavior: now,
      they should get an error, and hopefully, reading the new and
      improved documentation, should be able to resolve it in their
      projects by adding code to install or copy in such libraries prior
      to calling fixup_bundle.
      
      Whew.
      c2895f48
  31. 23 Nov, 2010 1 commit
  32. 07 Sep, 2010 1 commit
    • Mike McQuaid's avatar
      Make bundle items writable before fixup (#9284) · 88fed668
      Mike McQuaid authored
      This ensures that any bundle items are made user writable before
      any attempt is made to alter them using install_name_tool. This is
      because MacPorts/Fink/Homebrew don't install libraries as writable.
      This fix is needed to allow fixup_bundle_item to work correctly
      when ingesting libraries installed by these package managers.
      88fed668