1. 22 Jun, 2015 1 commit
  2. 20 May, 2015 1 commit
  3. 20 Apr, 2015 1 commit
  4. 06 Mar, 2015 1 commit
    • Brad King's avatar
      Makefile: Fix multiple custom command outputs regression (#15116) · 66a9c90c
      Brad King authored
      In commit v3.2.0-rc1~272^2~2 (Makefile: Fix rebuild with multiple custom
      command outputs, 2014-12-05) we changed the generated makefile pattern
      for multiple outputs from
      
        out1: depends...
                commands...
        out2: out1
      
      to
      
        out1 out2: depends...
                commands...
      
      This was based on the incorrect assumption that make tools would treat
      this as a combined output rule and run the command(s) exactly once for
      them.  It turns out that instead this new pattern is equivalent to
      
        out1: depends...
                commands...
        out2: depends...
                commands...
      
      so the commands may be run more than once.
      
      Some documents suggest using a "dedicated witness" stamp file:
      
        stamp: depends...
                rm -f stamp
                touch stamp.tmp
                commands...
                mv stamp.tmp stamp
        out1 out2: stamp
      
      However, if the commands fail the error message will refer to the stamp
      instead of any of the real outputs, which may be confusing to readers.
      Also, this approach seems to have the same behavior of the original
      approach that motiviated the above commit: multiple invocations are
      needed to bring consumers of the outputs up to date.
      
      Instead we can return to the original approach but add an explicit
      touch to each extra output rule:
      
        out1: depends...
                commands...
        out2: out1
                touch -c out2
      
      This causes make tools to recognize that all outputs have changed and
      therefore to execute any commands that consume them.
      66a9c90c
  5. 06 Feb, 2015 1 commit
  6. 11 Jan, 2015 1 commit
  7. 05 Dec, 2014 1 commit
  8. 07 May, 2014 1 commit
  9. 08 Apr, 2014 1 commit
  10. 27 Mar, 2014 1 commit
    • Jiri Malak's avatar
      Makefile: Generate single-quoted object lists for Watcom · 423009c1
      Jiri Malak authored and Brad King's avatar Brad King committed
      Drop the CMAKE_NO_QUOTED_OBJECTS internal variable from the Makefile
      generators.  The underlying problem is with the Watcom linker, not with
      WMake.  The Watcom linker wants object files to be single-quoted.  Add
      <LINK-RULE>_USE_WATCOM_QUOTE platform information variables to tell the
      generators to use Watcom-style single quotes for object files on link
      lines.
      
      On Windows, Watcom uses the GetCommandLine API to get the original
      command-line string and do custom parsing that expects single quotes.
      On POSIX systems, Watcom approximates the original command line by
      joining all argv[] entries separated by a single space.  Therefore we
      need to double-quote the single-quoted arguments so that the shell does
      not consume them and they are available for the parser to see.
      423009c1
  11. 11 Mar, 2014 1 commit
    • Stephen Kelly's avatar
      Remove some c_str() calls. · 21c573f6
      Stephen Kelly authored
      Use the clang RemoveCStrCalls tool to automatically migrate the
      code. This was only run on linux, so does not have any positive or
      negative effect on other platforms.
      21c573f6
  12. 08 Mar, 2014 3 commits
  13. 05 Mar, 2014 2 commits
  14. 04 Mar, 2014 1 commit
  15. 26 Feb, 2014 2 commits
    • Brad King's avatar
      MSVC: Add properties to configure compiler PDB files (#14763) · 0ea3aee8
      Brad King authored
      Since commit v2.8.12~437^2~2 (VS: Separate compiler and linker PDB files
      2013-04-05) we no longer set /Fd with the PDB_NAME or PDB_OUTPUT_DIRECTORY
      properties.  Those properties now exclusively handle linker PDB files.
      Since STATIC libraries do not link their compiler PDB file becomes more
      important.  Add new target properties "COMPILE_PDB_NAME[_<CONFIG>]" and
      "COMPILE_PDB_OUTPUT_DIRECTORY[_<CONFIG>]" to specify the compiler PDB
      file location and pass the value to the MSVC /Fd option.
      0ea3aee8
    • Brad King's avatar
      MSVC: Add properties to configure compiler PDB files (#14762) · fba51b09
      Brad King authored
      Since commit v2.8.12~437^2~2 (VS: Separate compiler and linker PDB files
      2013-04-05) we no longer set /Fd with the PDB_NAME or PDB_OUTPUT_DIRECTORY
      properties.  Those properties now exclusively handle linker PDB files.
      Since STATIC libraries do not link their compiler PDB file becomes more
      important.  Add new target properties "COMPILE_PDB_NAME[_<CONFIG>]" and
      "COMPILE_PDB_OUTPUT_DIRECTORY[_<CONFIG>]" to specify the compiler PDB
      file location and pass the value to the MSVC /Fd option.
      fba51b09
  16. 24 Feb, 2014 1 commit
  17. 02 Jan, 2014 1 commit
    • Brad King's avatar
      Replace <OBJECT_DIR> rule placeholder consistently (#14667) · 03f3b4e7
      Brad King authored
      The <OBJECT_DIR> placeholder is supposed to be the base intermediate
      files directory for the current target.  This is how it gets replaced
      during link line generation.  However, during compile line generation
      we replace it with the directory containing the current object file
      which may be a subdirectory.  Fix replacement of <OBJECT_DIR> in the
      generated compile lines to be the base intermediate files directory.
      
      This was expoxed by commit 42ba1b08 (VS: Separate compiler and linker
      PDB files, 2013-04-05) when we added a "/Fd<OBJECT_DIR>/" flag to the
      MSVC compile line in order to match the VS IDE default compiler program
      database location in the intermediate files directory.  For source files
      in a subdirectory relative to the current target this caused the wrong
      location to be used for the compiler program database.  This becomes
      particularly important when using precompiled headers.
      
      While at it, use the cmTarget::GetSupportDirectory method to compute the
      intermediate files directory for the current target instead of repeating
      the logic in a few places.
      03f3b4e7
  18. 10 Dec, 2013 1 commit
    • Stephen Kelly's avatar
      Remove INTERFACE build targets. · 97fae68b
      Stephen Kelly authored
      Commit b04f3b9a (Create make rules for INTERFACE_LIBRARY
      targets., 2013-08-21) extended the makefile generator to create
      build targets for INTERFACE_LIBRARY targets. No other generators
      were extended with this feature.
      
      This conflicts with the feature of whitelisting of target properties
      read from INTERFACE_LIBRARY targets. The INTERFACE_* properties
      of the INTERFACE_LIBRARY may legitimately contain TARGET_PROPERTY
      generator expressions for reading properties from the 'head target'.
      The 'head target' would be the INTERFACE_LIBRARY itself when creating
      the build rules for it, which means that non-whitelisted properties
      would be read.
      97fae68b
  19. 25 Nov, 2013 1 commit
    • Stephen Kelly's avatar
      INTERFACE_LIBRARY: Avoid codepaths which set unneeded properties. · 0bfcb450
      Stephen Kelly authored
      As an INTERFACE_LIBRARY has no direct link dependencies, we can
      short-circuit in cmGeneratorExpressionEvaluator and
      in cmGlobalGenerator::CheckLocalGenerators.
      
      As they do not generate any output directly, any generate- or install-
      related code acn also be short-circuited. Many of the local generators
      already do this.
      
      Because only INTERFACE related properties make sense on INTERFACE_LIBRARY
      targets, avoid setting other properties, for example via defaults.
      0bfcb450
  20. 22 Nov, 2013 1 commit
  21. 21 Oct, 2013 1 commit
    • Stephen Kelly's avatar
      Create make rules for INTERFACE_LIBRARY targets. · b04f3b9a
      Stephen Kelly authored and Brad King's avatar Brad King committed
      The result is that the depends of the target are created.
      
      So,
      
       add_library(somelib foo.cpp)
       add_library(anotherlib EXCLUDE_FROM_ALL foo.cpp)
       add_library(extra EXCLUDE_FROM_ALL foo.cpp)
       target_link_libraries(anotherlib extra)
      
       add_library(iface INTERFACE)
       target_link_libraries(iface INTERFACE anotherlib)
      
      Executing 'make iface' will result in the anotherlib and extra targets
      being made.
      
      Adding a regular executable to the INTERFACE of an INTERFACE_LIBRARY
      will not result in the executable being built with 'make iface' because
      of the logic in cmComputeTargetDepends::AddTargetDepend.
      
      So far, this is implemented only for the Makefile generator. Other
      generators will follow if this feature is possible for them.
      
      Make INTERFACE_LIBRARY targets part of the all target by default.
      Test this by building the all target and making the expected library
      EXCLUDE_FROM_ALL.
      b04f3b9a
  22. 31 Jul, 2013 1 commit
  23. 12 Jul, 2013 1 commit
  24. 07 Jun, 2013 1 commit
    • Stephen Kelly's avatar
      Use --sysroot when cross compiling. · de4da665
      Stephen Kelly authored
      As CMAKE_ROOT_FIND_PATH can be a list, a new CMAKE_SYSROOT is
      introduced, which is never a list.
      
      The contents of this variable is passed to supporting compilers
      as --sysroot. It is also accounted for when processing implicit
      link directories reported by the compiler, and when generating
      RPATH information.
      de4da665
  25. 03 Jun, 2013 1 commit
  26. 23 May, 2013 1 commit
    • Clinton Stimpson's avatar
      Refactor how bundles and frameworks are supported. · 373faae5
      Clinton Stimpson authored and Brad King's avatar Brad King committed
      Make handling of directory separators consistent between
      non-bundle and bundle code.
      
      Remove xcode specific flag from cmTarget when getting install_name.
      
      Add (more) consistent convenience functions in cmTarget to get
      directories inside of bundles and frameworks to add files to.
      
      This refactor also fixes bug #12263 where frameworks
      had the wrong install name when SKIP_BUILD_RPATH.
      
      Also make install_name for frameworks consistent between Makefile
      and Xcode generator.
      373faae5
  27. 20 Nov, 2012 1 commit
    • Stephen Kelly's avatar
      Always use the auto_ptr from cmsys. · ddc05205
      Stephen Kelly authored
      This is for consistency throughout cmake. The cmsys version exists
      becaues uses of auto_ptr types as return types does not work with
      some implementations in ancient compilers.
      ddc05205
  28. 01 Oct, 2012 1 commit
  29. 25 Sep, 2012 1 commit
  30. 19 Sep, 2012 2 commits
  31. 17 Jul, 2012 4 commits
  32. 30 Apr, 2012 1 commit
    • Modestas Vainius's avatar
      Support building shared libraries or modules without soname (#13155) · e1409ac5
      Modestas Vainius authored and Brad King's avatar Brad King committed
      Add a boolean target property NO_SONAME which may be used to disable
      soname for the specified shared library or module even if the platform
      supports it.  This property should be useful for private shared
      libraries or various plugins which live in private directories and have
      not been designed to be found or loaded globally.
      
      Replace references to <CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG> and
      hard-coded -install_name flags with a conditional <SONAME_FLAG> which is
      expanded to the value of the CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG
      definition as long as soname supports is enabled for the target in
      question.  Keep expanding CMAKE_SHARED_LIBRARY_SONAME_${LANG}_FLAG in
      rules in case third party projects still use it.  Such projects would
      not yet use NO_SONAME so the adjacent <TARGET_SONAME> will always be
      expanded.  Make <TARGET_INSTALLNAME_DIR> NO_SONAME aware as well.  Since
      -install_name is soname on OS X, this should not be a problem if this
      variable is expanded only if soname is enabled.
      
      The Ninja generator performs rule variable substitution only once
      globally per rule to put its own placeholders.  Final substitution is
      performed by ninja at build time.  Therefore we cannot conditionally
      replace the soname placeholders on a per-target basis.  Rather than
      omitting $SONAME from rules.ninja, simply do not write its contents for
      targets which have NO_SONAME.  Since 3 variables are affected by
      NO_SONAME ($SONAME, $SONAME_FLAG, $INSTALLNAME_DIR), set them only if
      soname is enabled.
      e1409ac5