1. 09 Jun, 2014 5 commits
  2. 15 Apr, 2014 1 commit
    • Brad King's avatar
      VS: Use full path to sources to allow deeper trees with VS >= 10 · 0d048384
      Brad King authored
      
      
      As explained in cmVisualStudio10TargetGenerator::WriteSource comments,
      VS tools append relative paths to the current directory, e.g.
      
       c:\path\to\current\dir\..\..\..\relative\path\to\source.c
      
      and fail if this is over 250 charaters or so.  Previously we used a full
      path only if no relative path could be constructed with a leading "../"
      sequence that does not escape the source or build tree.  This means that
      long relative paths can be generated when the build tree is inside the
      source tree, and can cause build failures due to the above path
      concatenation problem.
      
      Teach cmVisualStudio10TargetGenerator::ConvertPath to ask the Convert
      method to honor CMAKE_USE_RELATIVE_PATHS.  This will cause it to use
      full paths by default but still give users the option of getting the
      relative paths when possible.
      Suggested-by: default avatarJosh Green <inbilla@gmail.com>
      0d048384
  3. 02 Apr, 2014 2 commits
    • Stephen Kelly's avatar
      cmTarget: Make the source files depend on the config. · e6971df6
      Stephen Kelly authored
      Disallow the use of config-specific source files with
      the Visual Studio and Xcode generators. They don't have
      any way to represent the condition currently.
      
      Use the same common-config API in cmQtAutoGenerators. While
      it accepts config-specific files, it doesn't have to support
      multiple configurations yet.
      
      Loop over the configs in cmTargetTraceDependencies
      and cmGlobalGenerator::WriteSummary and consume all source
      files.
      
      Loop over the configs in cmComputeTargetDepends and compute the
      object library dependencies for each config.
      e6971df6
    • Stephen Kelly's avatar
      cmTarget: Allow any generator expression in SOURCES property. · e5da9e51
      Stephen Kelly authored
      Remove use of UseObjectLibraries from Makefile and Ninja generators. It
      is not needed now because those generators use GetExternalObjects
      which already contains the objects from object libraries.
      
      The VS10 generator calls both the UseObjectLibraries and the GetExternalObjects
      methods. Ensure that duplicates are not created by skipping objects
      from object libraries in handling of GetExternalObjects.
      
      Similarly, fix VS6, VS7 and Xcode object handling by skipping
      external objects from OBJECT_LIBRARY usage as appropriate.
      
      The error message in the BadSourceExpression1 test is now reported
      by the generator expression evaluator, so it has different text.
      e5da9e51
  4. 14 Mar, 2014 1 commit
  5. 13 Mar, 2014 2 commits
  6. 12 Mar, 2014 1 commit
    • Brad King's avatar
      Generalize cmCustomCommandGenerator to more fields · bc993f27
      Brad King authored
      Until now the cmCustomCommandGenerator was used only to compute the
      command lines of a custom command.  Generalize it to get the comment,
      working directory, dependencies, and outputs of custom commands.  Update
      use in all generators to support this.
      bc993f27
  7. 08 Mar, 2014 2 commits
  8. 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
  9. 24 Feb, 2014 1 commit
  10. 22 Jan, 2014 1 commit
  11. 09 Jan, 2014 2 commits
  12. 08 Jan, 2014 1 commit
  13. 07 Jan, 2014 1 commit
  14. 11 Dec, 2013 1 commit
  15. 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
  16. 19 Nov, 2013 1 commit
  17. 14 Nov, 2013 1 commit
  18. 30 Oct, 2013 1 commit
  19. 07 Oct, 2013 1 commit
    • Stephen Kelly's avatar
      Add the INTERFACE_LIBRARY target type. · fe732264
      Stephen Kelly authored
      This target type only contains INTERFACE_* properties, so it can be
      used as a structural node. The target-specific commands enforce
      that they may only be used with the INTERFACE keyword when used
      with INTERFACE_LIBRARY targets. The old-style target properties
      matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for
      this target type.
      
      The name of the INTERFACE_LIBRARY must match a validity generator
      expression. The validity is similar to that of an ALIAS target,
      but with the additional restriction that it may not contain
      double colons. Double colons will carry the meaning of IMPORTED
      or ALIAS targets in CMake 2.8.13.
      
      An ALIAS target may be created for an INTERFACE library.
      
      At this point it can not be exported and does not appear in the
      buildsystem and project files are not created for them. That may
      be added as a feature in a later commit.
      
      The generators need some changes to handle the INTERFACE_LIBRARY
      targets returned by cmComputeLinkInterface::GetItems. The Ninja
      generator does not use that API, so it doesn't require changes
      related to that.
      fe732264
  20. 26 Aug, 2013 1 commit
  21. 05 Aug, 2013 1 commit
  22. 01 Aug, 2013 1 commit
  23. 31 Jul, 2013 2 commits
  24. 11 Jul, 2013 1 commit
  25. 28 Jun, 2013 2 commits
    • Brad King's avatar
      VS12: Generate flag tables from MSBuild v120 tool files · e99d7b1c
      Brad King authored
      Run cmparseMSBuildXML.py on cl.xml, lib.xml, and link.xml to generate
      our flag tables:
      
       python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/v120/1033/cl.xml" > cmVS12CLFlagTable.h
       python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/v120/1033/lib.xml" > cmVS12LibFlagTable.h
       python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/v120/1033/link.xml" > cmVS12LinkFlagTable.h
      
      Fix up the declaration names at the top of each file.  Finally, teach
      cmVisualStudio10TargetGenerator to select the version of the table
      matching the version of VS.
      e99d7b1c
    • Jonas Andersen's avatar
      VS: Add Resx configuration to the vcxproj file · 6c9712c4
      Jonas Andersen authored
      In my project group we are using CMake to generate c++/cli winform
      projects and I noticed the work done in commit 79ec7868 (VS: Add Windows
      Forms Support, 2013-04-29) was in the right direction for solving some
      of the problems we were facing.
      
      The changes as submitted was breaking some functionality in our
      projects, so I made some changes that fixes our problems and I believe
      that it will also work for others.
      
      * Resx files did not link correctly with the winform h-file so I added
        the Resx configuration to the vcxproj file.
      
      * I removed the functionality for setting <CLRSupport> true for the
        project based on if an resx-file is pressent.  This is preventing
        us from using native cpp code.  Also this do not address that some
        projects will need to set other options like clr:pure, clr:safe.
        This could be implemented as a cmake option, so it is possible to
        specify exactly what is needed.  Existing VSWindowsFormsResx Test
        project is updated so it will be working with my changes.
      6c9712c4
  26. 27 Jun, 2013 1 commit
    • Brad King's avatar
      Refactor target COMPILE_OPTIONS and COMPILE_FLAGS handling · d221eac8
      Brad King authored
      Replace the cmLocalGenerator GetCompileOptions method with an
      AddCompileOptions method since all call sites of the former simply
      append the result to a flags string anyway.
      
      Add a "lang" argument to AddCompileOptions and move the
      CMAKE_<LANG>_FLAGS_REGEX filter into it.  Move the call sites in each
      generator to a location that has both the language and configuration
      available.  In the Makefile generator this also moves the flags from
      build.make to flags.make where they belong.
      d221eac8
  27. 21 Jun, 2013 1 commit
  28. 14 Jun, 2013 1 commit
  29. 02 Jun, 2013 1 commit
    • Stephen Kelly's avatar
      Add cmLocalGenerator::GetCompileOptions. · 35496761
      Stephen Kelly authored
      Currently it only adds the contents of the COMPILE_FLAGS target
      property, but it can be extended to handle a new COMPILE_OPTIONS
      generator expression enabled property.
      35496761