date:20130207

[cmake-developers] [CMake 0013895]: CMake docs: suggestion for impovement in OpenMP section

2013-02-07 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=13895 
== 
Reported By:Sylwester Arabas
Assigned To:
== 
Project:CMake
Issue ID:   13895
Category:   Documentation
Reproducibility:N/A
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-02-07 05:58 EST
Last Modified:  2013-02-07 05:58 EST
== 
Summary:CMake docs: suggestion for impovement in OpenMP
section
Description: 
The CMake FindOpenMP docs say that If the compiler supports OpenMP, the flags
required to compile with openmp support are set. This might be misleading as
these flags are not set for any targets, but instead some variables with these
flags inside are made available to the user.

Furthermore, it might be worth to mention how to use these variables, e.g.:

if (OPENMP_FOUND)
  set_target_properties(... PROPERTIES LINK_FLAGS ${OpenMP_CXX_FLAGS})
  set_target_properties(... PROPERTIES COMPILE_FLAGS ${OpenMP_CXX_FLAGS})
endif()

HTH,
Sylwester
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-02-07 05:58 Sylwester ArabasNew Issue
==

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Depends information in buildsystem files

2013-02-07 Thread Brad King

On 02/06/2013 08:27 PM, Stephen Kelly wrote:
 I've pushed a branch with some addtional fixes for various issues in 
 generator expressions. 

Thanks, those all look good.  I presume you're finding these by
trying to use the new features for Qt5, KDE, and Boost?  How else?

 One of the issues relates to depends information in the build dir. I fixed 
 the situation in the makefile generator by expanding the COMPILE_DEFINITIONS 
 before writing out the DependsInfo.cmake file.

Good catch.

 The Ninja generator doesn't 
 use such a file, but from my porcelain test it seems to already detect the 
 INTERFACE content appropriately. I didn't check how that works.

The Ninja generator depends on the toolchain to support gcc -M style
flags so it always computes the dependencies that the compiler sees.

The Makefile generators are the only ones that implement their own
dependency scanning rather than relying on the native build tools.

 It occurs to me though that this could be not just one bug but a class of 
 bugs. A similar issue could exist for the other generators, and anywhere 
 else that cmake generates 'buildsystem artifacts' which make need to be 
 evaluated as generator expressions, or may need to take INTERFACE content of 
 dependencies into account. 

Every generator expression should be evaluated as it passes through the
generators before being written out to disk anywhere for the native
build system to see.  Are you asking whether there could be places that
the expressions still leak through by accident?  If so, I guess users
will discover them soon enough ;)

The most likely source of such bugs would be interfaces whose generation
is re-implemented by each generator rather than passing through a central
evaluation point.  If such a case is discovered then the best fix would
be to re-factor things to centralize the relevant evaluations.

 Another possible candidate is target_LIB_DEPENDS in the cache. Currently, 
 cmTarget::AddLinkLibrary aborts if a generator expression is found before 
 populating that cache variable. Is that appropriate?

Those variables are purely historical and should not be populated with
any new interfaces.

-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Depends information in buildsystem files

2013-02-07 Thread Stephen Kelly

Brad King wrote:

 On 02/06/2013 08:27 PM, Stephen Kelly wrote:
 I've pushed a branch with some addtional fixes for various issues in
 generator expressions.
 
 Thanks, those all look good.  I presume you're finding these by
 trying to use the new features for Qt5, KDE, and Boost?  How else?

Yes. Many of them I had a on a mental todo list (eg replace 
isGeneratorExpression with something - but what? static bool 
cmGeneratorExpression::Contains? Something else?). Others I just found by 
reviewing the code again and trying things out. 

The LINK_LIBRARIES fix for the DagChecker I found while testing 
https://codereview.qt-
project.org/#patch,sidebyside,46437,8,src/corelib/Qt5CoreConfigExtras.cmake.in 
because multiple-config properties are populated there. 

I checked FindQt4, and we only populate the noconfig variant. I'm not sure 
if that's a bug or not. As we set the IMPORTED_CONFIGURATIONS in FindQt4 
too, it might be better to loop over them there too.

 
 One of the issues relates to depends information in the build dir. I
 fixed the situation in the makefile generator by expanding the
 COMPILE_DEFINITIONS before writing out the DependsInfo.cmake file.
 
 Good catch.
 
 The Ninja generator doesn't
 use such a file, but from my porcelain test it seems to already detect
 the INTERFACE content appropriately. I didn't check how that works.
 
 The Ninja generator depends on the toolchain to support gcc -M style
 flags so it always computes the dependencies that the compiler sees.
 
 The Makefile generators are the only ones that implement their own
 dependency scanning rather than relying on the native build tools.

Great.

 
 It occurs to me though that this could be not just one bug but a class of
 bugs. A similar issue could exist for the other generators, and anywhere
 else that cmake generates 'buildsystem artifacts' which make need to be
 evaluated as generator expressions, or may need to take INTERFACE content
 of dependencies into account.
 
 Every generator expression should be evaluated as it passes through the
 generators before being written out to disk anywhere for the native
 build system to see.  Are you asking whether there could be places that
 the expressions still leak through by accident?  If so, I guess users
 will discover them soon enough ;)

Yes, that's what I'm asking. More accurately, I was wondering about possible 
situations similar to the DependsInfo.cmake issue in other generators. If 
other generators don't do depends tracking like the makefile generator 
though I'm sure that's fine and users can find the rest.

 
 The most likely source of such bugs would be interfaces whose generation
 is re-implemented by each generator rather than passing through a central
 evaluation point.  If such a case is discovered then the best fix would
 be to re-factor things to centralize the relevant evaluations.

Yes, that's something to be careful of in the future as genexes are used 
more.

For now (and in the future), I think a more likely source of bugs is reading 
a property which didn't have generator expressions before and now does (like 
the recent automoc bug fix). From grepping in Source it looks like relevant 
properties like LINK_INTERFACE_LIBRARIES are fine, as are properties like 
COMPILE_DEFINTIONS.

A concern though is this in CMakeExpandImportedTargets.cmake:

 get_target_property(_linkInterfaceLibs ${_CURRENT_LIB} 
   IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )

That macro won't work if the IMPORTED_LINK_INTERFACE_LIBRARIES_ has 
generator expressions. Wherever that macro is needed though, cmake should 
probably be updated to have built-in support for imported targets probably.

While we can update the cmake code for that, we'd probably have to update 
the macro to be able to handle generator expressions too somehow. 

 
 Another possible candidate is target_LIB_DEPENDS in the cache.
 Currently, cmTarget::AddLinkLibrary aborts if a generator expression is
 found before populating that cache variable. Is that appropriate?
 
 Those variables are purely historical and should not be populated with
 any new interfaces.

Great, that's what I thought.

Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Depends information in buildsystem files

2013-02-07 Thread Brad King

On 02/07/2013 09:02 AM, Stephen Kelly wrote:
 A concern though is this in CMakeExpandImportedTargets.cmake:
 
  get_target_property(_linkInterfaceLibs ${_CURRENT_LIB} 
IMPORTED_LINK_INTERFACE_LIBRARIES_${_importedConfigToUse} )
 
 That macro won't work if the IMPORTED_LINK_INTERFACE_LIBRARIES_ has 
 generator expressions. Wherever that macro is needed though, cmake should 
 probably be updated to have built-in support for imported targets probably.

There was extensive discussion of this when that macro was first added.
The try_compile projects are their own projects.  I said at the time
that those projects should have to import any targets they want to use
just like the containing project does.  The problem is that means the
CMake-provided macros like check_symbol_exists cannot be used on the
imported libraries.

The full solution is to refactor things enough that a new kind of
try_compile can be implemented.  It should push the configuration
process state on a stack, run more CMake code in the isolated state
to add some targets, and then generate the build system for them
directly out of the temporary configuration state.  Finally the
configuration stack would be popped back to the try_compile call and
the result variable would be set.  This would allow the full state
of the main project to be used for generation of a try_compile,
including imported targets.

Achieving this will require making the entire configuration state
read-only during generation.  Currently the generators do destructive
updates in a few cases.  That would have to be fixed.  A start to this
is cmGeneratorTarget, but until export() is generate-time-only we
cannot fully move to that.

Meanwhile, fixing the macro will require a CMake-language interface
for immediate evaluation of generator expressions.  Of course that
would introduce a new case like the configure-time export() which
we want to drop so much :(

-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Fwd: [Bug 894805] Re: QT_IMPORTS_DIR is not defined when no QML plugins are installed

2013-02-07 Thread Clinton Stimpson

This is interesting...

The intent of FindQt4.cmake is to find the Qt installation so it can be used.  
But in that bug report, the QT_IMPORTS_DIR variable is being used to determine 
the qt_dir/imports directory to install their qml plugins - which is into 
the Qt installation.  Its a problem for them because there is no imports 
directory to begin with.

In other words... they have something like this:
find_package(Qt4)
...
install( ... DESTINATION ${QT_IMPORTS_DIR})


Is there a CMake convention for this kind of thing?


On Monday, February 04, 2013 09:13:06 AM Bill Hoffman wrote:
 FYI
 
  Original Message 
 Subject: [Bug 894805] Re: QT_IMPORTS_DIR is not defined when no QML
 plugins   are installed
 Date: Thu, 31 Jan 2013 19:30:37 -
 From: Launchpad Bug Tracker 894...@bugs.launchpad.net
 Reply-To: Bug 894805 894...@bugs.launchpad.net
 To: cm...@packages.qa.debian.org
 
 ** Branch linked: lp:ubuntu/raring-proposed/cmake
-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Depends information in buildsystem files

2013-02-07 Thread Stephen Kelly

Brad King wrote:
 The full solution is to refactor things enough that a new kind of
 try_compile can be implemented.  It should push the configuration
 process state on a stack, run more CMake code in the isolated state
 to add some targets, and then generate the build system for them
 directly out of the temporary configuration state.  Finally the
 configuration stack would be popped back to the try_compile call and
 the result variable would be set.  This would allow the full state
 of the main project to be used for generation of a try_compile,
 including imported targets.

Are you sure? It seems to me it would be much easier and less duplicative to 
add a way to specify TARGETS in try_compile, and in cmCoreTryCompile, 
generate the IMPORTED targets there with whatever properties they have.


 cmake_minimum_required(VERSION 2.8)

 project(iface)

 find_package(Qt4 REQUIRED)

 include(CMakeParseArguments)

 macro(CHECK_CXX_SOURCE_COMPILES_COPY SOURCE)

   set(oneValueArgs VAR)
   set(multiValueArgs TARGETS)
   cmake_parse_arguments(_CSC ${options} ${oneValueArgs} 
${multiValueArgs} ${ARGN} )

   if(NOT ${_CSC_VAR} MATCHES ^${_CSC_VAR}$)
 return()
   endif()

   file(WRITE ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/src.cxx
 ${SOURCE}\n)

   message(STATUS Performing Test ${_CSC_VAR})
   try_compile(${_CSC_VAR}
 ${CMAKE_BINARY_DIR}
 ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/src.cxx

 # NOTE: This is new!
 TARGETS ${_CSC_TARGETS}
 OUTPUT_VARIABLE OUTPUT)

   foreach(_regex ${_FAIL_REGEX})
 if(${OUTPUT} MATCHES ${_regex})
   set(${VAR} 0)
 endif()
   endforeach()

   if(${_CSC_VAR})
 set(${_CSC_VAR} 1 CACHE INTERNAL Test ${_CSC_VAR})
 message(STATUS Performing Test ${_CSC_VAR} - Success)
 file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeOutput.log
   Performing C++ SOURCE FILE Test ${_CSC_VAR} succeded with the 
following output:\n
   ${OUTPUT}\n
   Source file was:\n${SOURCE}\n)
   else()
 message(STATUS Performing Test ${_CSC_VAR} - Failed)
 set(${_CSC_VAR}  CACHE INTERNAL Test ${_CSC_VAR})
 file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeError.log
   Performing C++ SOURCE FILE Test ${_CSC_VAR} failed with the 
following output:\n
   ${OUTPUT}\n
   Source file was:\n${SOURCE}\n)
   endif()
 endmacro()


 CHECK_CXX_SOURCE_COMPILES_COPY(
 #include QApplication

 #ifndef QT_GUI_LIB
 #error Expected QT_GUI_LIB
 #endif
 #ifndef QT_CORE_LIB
 #error Expected QT_CORE_LIB
 #endif

 int main(int argc, char **argv)
 { QApplication app(argc, argv); app.instance(); return 0; }
 
   VAR
 TC_RESULT
   TARGETS
 Qt4::QtGui Qt4::QtCore
 )

 message(TC_RESULT : ${TC_RESULT})


I pushed the try_compile_targets topic to my clone as a proof of concept, 
but it would likely need to be reworked from scratch (eg a 
cmExportFileGenerator subclass which can re-export imported targets). 

Any reason not to do it that way?

Thanks,

Steve.



--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Depends information in buildsystem files

2013-02-07 Thread Stephen Kelly

Brad King wrote:

 The full solution is to refactor things enough that a new kind of
 try_compile can be implemented.  It should push the configuration
 process state on a stack, run more CMake code in the isolated state
 to add some targets, and then generate the build system for them
 directly out of the temporary configuration state.  Finally the
 configuration stack would be popped back to the try_compile call and
 the result variable would be set.  This would allow the full state
 of the main project to be used for generation of a try_compile,
 including imported targets.

Just to tie things together, this came up before:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5180

Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Depends information in buildsystem files

2013-02-07 Thread Brad King

On 02/07/2013 11:42 AM, Stephen Kelly wrote:
 Are you sure?

Well, my proposal would be sufficient but may not be necessary
(i.e. overkill).

 It seems to me it would be much easier and less duplicative to 
 add a way to specify TARGETS in try_compile, and in cmCoreTryCompile, 
 generate the IMPORTED targets there with whatever properties they have.

...and in CMakeExpandImportedTargets handle imported targets in
CMAKE_REQUIRED_LIBRARIES using this underlying CMake feature, yes.

 I pushed the try_compile_targets topic to my clone as a proof of concept, 
 but it would likely need to be reworked from scratch (eg a 
 cmExportFileGenerator subclass which can re-export imported targets). 

Yes.  Also along those lines, I've several times seen requests to
allow install(TARGETS) to re-install an imported target.  It is
usually requested by people wanting to package dependencies of
a project for distribution with CPack.  A similar re-exporting
feature in cmExportFileGenerator would help with that.

-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Fwd: [Bug 894805] Re: QT_IMPORTS_DIR is not defined when no QML plugins are installed

2013-02-07 Thread Stephen Kelly

Clinton Stimpson wrote:

 This is interesting...
 
 The intent of FindQt4.cmake is to find the Qt installation so it can be
 used. But in that bug report, the QT_IMPORTS_DIR variable is being used to
 determine the qt_dir/imports directory to install their qml plugins -
 which is into
 the Qt installation.  Its a problem for them because there is no imports
 directory to begin with.
 
 In other words... they have something like this:
 find_package(Qt4)
 ...
 install( ... DESTINATION ${QT_IMPORTS_DIR})
 
 
 Is there a CMake convention for this kind of thing?
 

Another relevant question is whether there is a Qt convention for this kind 
of thing.

From the bug report:

   When requiring the Qt4 package in a CMakeLists.txt, among the
   available variables the one called QT_IMPORTS_DIR should point to
   where QML plugins are to be installed (its value would typically be
   /usr/lib/qt4/imports).

This is not true. The QT_INSTALL_IMPORTS reported by qmake does not have the 
meaning where QML plugins are to be installed. It has the meaning where 
QML assets from Qt itself are installed.

That said, the reported problem in the bug report, that qmake reports the 
path, but cmake does not make it available, seems like something to look 
into.

Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Fwd: [Bug 894805] Re: QT_IMPORTS_DIR is not defined when no QML plugins are installed

2013-02-07 Thread Clinton Stimpson

On Thursday, February 07, 2013 05:51:59 PM Stephen Kelly wrote:
 Clinton Stimpson wrote:
  This is interesting...
  
  The intent of FindQt4.cmake is to find the Qt installation so it can be
  used. But in that bug report, the QT_IMPORTS_DIR variable is being used to
  determine the qt_dir/imports directory to install their qml plugins -
  which is into
  the Qt installation.  Its a problem for them because there is no imports
  directory to begin with.
  
  In other words... they have something like this:
  find_package(Qt4)
  ...
  install( ... DESTINATION ${QT_IMPORTS_DIR})
  
  
  Is there a CMake convention for this kind of thing?
 
 Another relevant question is whether there is a Qt convention for this kind
 of thing.
 
 From the bug report:
 
When requiring the Qt4 package in a CMakeLists.txt, among the
available variables the one called QT_IMPORTS_DIR should point to
where QML plugins are to be installed (its value would typically be
/usr/lib/qt4/imports).
 
 This is not true. The QT_INSTALL_IMPORTS reported by qmake does not have the
 meaning where QML plugins are to be installed. It has the meaning where
 QML assets from Qt itself are installed.
 
 That said, the reported problem in the bug report, that qmake reports the
 path, but cmake does not make it available, seems like something to look
 into.
 

Do you have something in mind when you say it should be looked into?

qmake is reporting a non-existant directory, and CMake doesn't make it 
available because it doesn't exist (not found).

I'm leaning towards saying this is a user error because the user is assuming 
it has the meaning where QML plugins are to be installed.

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0013896]: CMAKE_CL_64 incorrectly set for CXX projects

2013-02-07 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=13896 
== 
Reported By:Leszek Swirski
Assigned To:
== 
Project:CMake
Issue ID:   13896
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2013-02-07 12:33 EST
Last Modified:  2013-02-07 12:33 EST
== 
Summary:CMAKE_CL_64 incorrectly set for CXX projects
Description: 
CMAKE_CL_64 only checks the value of MSVC_C_ARCHITECTURE_ID, not
MSVC_CXX_ARCHITECTURE_ID.

This means that CXX only projects [projects defined as project(x CXX)] and
CXX-first projects [projects defined as project(x CXX C) rather than project(x C
CXX)] do not correctly set CMAKE_CL_64 = 1 when MSVC_CXX_ARCHITECTURE_ID = x64

Steps to Reproduce: 
Using a Visual Studio x64 command shell, running cmake on:

-- CMakeLists.txt
project(test CXX)
message(MSVC_CXX_ARCHITECTURE_ID = ${MSVC_CXX_ARCHITECTURE_ID})
message(CMAKE_CL_64 = ${CMAKE_CL_64})

prints:

MSVC_CXX_ARCHITECTURE_ID = x64
CMAKE_CL_64 = 0

and

-- CMakeLists.txt
project(test CXX C)
message(MSVC_C_ARCHITECTURE_ID = ${MSVC_C_ARCHITECTURE_ID})
message(MSVC_CXX_ARCHITECTURE_ID = ${MSVC_CXX_ARCHITECTURE_ID})
message(CMAKE_CL_64 = ${CMAKE_CL_64})

prints:

MSVC_C_ARCHITECTURE_ID = x64
MSVC_CXX_ARCHITECTURE_ID = x64
CMAKE_CL_64 = 0

while the following

-- CMakeLists.txt
project(test C CXX)
message(MSVC_C_ARCHITECTURE_ID = ${MSVC_C_ARCHITECTURE_ID})
message(MSVC_CXX_ARCHITECTURE_ID = ${MSVC_CXX_ARCHITECTURE_ID})
message(CMAKE_CL_64 = ${CMAKE_CL_64})

prints:

MSVC_C_ARCHITECTURE_ID = x64
MSVC_CXX_ARCHITECTURE_ID = x64
CMAKE_CL_64 = 1
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-02-07 12:33 Leszek Swirski New Issue
==

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] Fwd: [Bug 894805] Re: QT_IMPORTS_DIR is not defined when no QML plugins are installed

2013-02-07 Thread Stephen Kelly

Clinton Stimpson wrote:
 That said, the reported problem in the bug report, that qmake reports the
 path, but cmake does not make it available, seems like something to look
 into.
 
 
 Do you have something in mind when you say it should be looked into?
 
 qmake is reporting a non-existant directory, and CMake doesn't make it
 available because it doesn't exist (not found).

Yes, I see. It surprised me that the imports would be non-existant, and I 
though that might mean an incomplete or broken Qt installation somehow.

My Qt 4.8 build has 

 Qt/  QtWebKit/

but my Qt from ubuntu packages does not have an imports dir:

 $ l /usr/lib/qt4/
demos/  examples/  plugins/

Maybe the contents of it are in a package I don't have installed. At least 
for me, that solves the mystery and is all the 'looking into' needed :).

 
 I'm leaning towards saying this is a user error because the user is
 assuming it has the meaning where QML plugins are to be installed.

Yes, I'd agree to that too. Otherwise you're inventing 'supported 
configurations' in cmake which are not really 'supported' by Qt (at least 
not officially).

I'll leave that choice up to you though.

Thanks,

Steve.



--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] INTERFACE_INCLUDE_DIRECTORIES on STATIC libs

2013-02-07 Thread Stephen Kelly

Brad King wrote:

 On 02/07/2013 01:40 PM, Stephen Kelly wrote:
 
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fecede0d9012f78470778cb049b2ab0231b4dcb7
 + If this variable is enabled, CMake automatically adds for each
 shared 
 + library target, module target and executable target, 
 + ${CMAKE_CURRENT_SOURCE_DIR} and ${CMAKE_CURRENT_BINARY_DIR} to the
 
 + INTERFACE_INCLUDE_DIRECTORIES.
 ...
 +  if(this-GetType() != cmTarget::SHARED_LIBRARY 
 + this-GetType() != cmTarget::MODULE_LIBRARY 
 + !this-IsExecutableWithExports())
 +{
 +return;
 +}
 
 Doesn't INTERFACE_INCLUDE_DIRECTORIES still make sense for static libs?
 

Yes. Updated now.

What about OBJECT_LIBRARYs ? I have no experience with them.

Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0013897]: Cross-compiling from Windows with a Linux-GCC toolchain exceeds max command line length during linking

2013-02-07 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=13897 
== 
Reported By:Eric Gross
Assigned To:
== 
Project:CMake
Issue ID:   13897
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-02-07 16:21 EST
Last Modified:  2013-02-07 16:21 EST
== 
Summary:Cross-compiling from Windows with a Linux-GCC
toolchain exceeds max command line length during linking
Description: 
When compiling using GCC on Windows as a non-cross-compile, CMake has code in
the platform files for using a response file to pass the objects to GCC's
linker. When cross-compiling to a Linux toolchain, this workaround is not used.
I was hitting this issue at around the 200-300 file count.

It seems that GCC supports the usage of response files across all OSes.
Additionally, it seems that there are some cases that on certain Linux
configurations (compiling natively) that they can run into the same issue as
Windows. I believe CMake should use response files under the situation I am
seeing (cross-compiling on Windows) and perhaps more universally.



Steps to Reproduce: 
I cross-compiled the GenICam GenAPI reference implementation from Windows to an
ARM/Linux target. GenApi's source includes components Xerces and Xalan, both
which have hundreds of files and hit this error. The error shown is an
unterminated string in sh.exe because the line is truncated.



Additional Information: 
To work around this I added the following into the macro section of
Linux-GNU.cmake (copied from the Windows version of that file):

set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_OBJECTS 1)
set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_INCLUDES 1)


  # We prefer @ for response files but it is not supported by gcc 3.
  execute_process(COMMAND ${CMAKE_${lang}_COMPILER} --version OUTPUT_VARIABLE
_ver ERROR_VARIABLE _ver)
  if(${_ver} MATCHES \\(GCC\\) 3\\.)
if(${lang} STREQUAL Fortran)
  # The GNU Fortran compiler reports an error:
  #   no input files; unwilling to write output files
  # when the response file is passed with -Wl,@.
  set(CMAKE_Fortran_USE_RESPONSE_FILE_FOR_OBJECTS 0)
else()
  # Use -Wl,@ to pass the response file to the linker.
  set(CMAKE_${lang}_RESPONSE_FILE_LINK_FLAG -Wl,@)
endif()
# The GNU 3.x compilers do not support response files (only linkers).
set(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_INCLUDES 0)
  elseif(CMAKE_${lang}_USE_RESPONSE_FILE_FOR_OBJECTS)
# Use @ to pass the response file to the front-end.
set(CMAKE_${lang}_RESPONSE_FILE_LINK_FLAG @)
  endif()  
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-02-07 16:21 Eric Gross New Issue
==

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] INTERFACE_INCLUDE_DIRECTORIES on STATIC libs

2013-02-07 Thread Brad King

On 02/07/2013 04:15 PM, Stephen Kelly wrote:
 What about OBJECT_LIBRARYs ? I have no experience with them.

Do you add any interface properties to any object libraries currently?
Do the new tcd() and tid() work for them, at least for the impl
properties (COMPILE_DEFINITIONS and INCLUDE_DIRECTORIES)?

Note that object libraries never appear in tll() calls as either
the LHS or RHS argument.  They are also never installed or exported.

It does make sense to publish INTERFACE_INCLUDE_DIRECTORIES and
INTERFACE_COMPILE_DEFINITIONS on object library targets, but we
do not need to chain to them automatically.  Consumers of an
object library already need to do

  add_executable(consumer $TARGET_OBJECTS:objlib)

so they could also do

  target_include_directories(consumer
$TARGET_PROPERTY:objlib,INTERFACE_INCLUDE_DIRECTORIES)
  target_compile_definitions(consumer
$TARGET_PROPERTY:objlib,INTERFACE_COMPILE_DEFINITIONS)

explicitly.

-Brad
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] INTERFACE_INCLUDE_DIRECTORIES on STATIC libs

2013-02-07 Thread Stephen Kelly

Brad King wrote:

 On 02/07/2013 04:15 PM, Stephen Kelly wrote:
 What about OBJECT_LIBRARYs ? I have no experience with them.
 
 Do you add any interface properties to any object libraries currently?

Nope. The only places where cmake populates interface properties are with 
the AppendBuildInterfaceIncludes method, and target_link_libraries().

 Do the new tcd() and tid() work for them, at least for the impl
 properties (COMPILE_DEFINITIONS and INCLUDE_DIRECTORIES)?

I would expect so. cmTargetPropCommandBase is not restrictive at all on the 
types of targets it expects (though maybe it should be... ?). It makes sense 
to allow the use of object libraries with those commands. I can maybe 
investigate tomorrow.

 
 Note that object libraries never appear in tll() calls as either
 the LHS or RHS argument.  They are also never installed or exported.

Right.

 It does make sense to publish INTERFACE_INCLUDE_DIRECTORIES and
 INTERFACE_COMPILE_DEFINITIONS on object library targets, but we
 do not need to chain to them automatically.  Consumers of an
 object library already need to do
 
   add_executable(consumer $TARGET_OBJECTS:objlib)
 
 so they could also do
 
   target_include_directories(consumer
 $TARGET_PROPERTY:objlib,INTERFACE_INCLUDE_DIRECTORIES)
   target_compile_definitions(consumer
 $TARGET_PROPERTY:objlib,INTERFACE_COMPILE_DEFINITIONS)
 
 explicitly.

Yes. This is a little inconvenient though. I wonder if we could allow tll 
with object libraries? The call would set the includes and defines just like 
any other target, and would not have any effect on linking, because that is 
not appropriate for object libraries anyway. 

I know it's a bit of a stretch, but if tll() is for managing usage 
requirements, it is sort of appropriate. Using tll with an INTERFACE library 
which has only includes and defines set on it would also not have any effect 
on linking, so there are other supports for the concept.

Thanks,

Steve.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0013898]: cpack fails to use some CPACK_RPM_PACKAGE_* variables in the generated rpm spec if their value is less than 3 characters long

2013-02-07 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=13898 
== 
Reported By:Jonathan M Davis
Assigned To:
== 
Project:CMake
Issue ID:   13898
Category:   CPack
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-02-07 19:15 EST
Last Modified:  2013-02-07 19:15 EST
== 
Summary:cpack fails to use some CPACK_RPM_PACKAGE_*
variables in the generated rpm spec if their value is less than 3 characters
long
Description: 
If you do set(CPACK_RPM_PACKAGE_AUTOREQPROV 0) or
set(CPACK_RPM_PACKAGE_AUTOREQPROV no), when using the RPM generator for cpack,
it has no effect on the RPM spec file which is generated. However, if you do 
set(CPACK_RPM_PACKAGE_AUTOREQPROV  no) or  set(CPACK_RPM_PACKAGE_AUTOREQPROV
no ), then it works.

Looking through CPackRPM.cmake, I suspect that it has to do with this section at
line 480:


  if(CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER}_TMP)
string(LENGTH ${_RPM_SPEC_HEADER} _PACKAGE_HEADER_STRLENGTH)
math(EXPR _PACKAGE_HEADER_STRLENGTH ${_PACKAGE_HEADER_STRLENGTH} - 1)
string(SUBSTRING ${_RPM_SPEC_HEADER} 1 ${_PACKAGE_HEADER_STRLENGTH}
_PACKAGE_HEADER_TAIL)
string(TOLOWER ${_PACKAGE_HEADER_TAIL} _PACKAGE_HEADER_TAIL)
string(SUBSTRING ${_RPM_SPEC_HEADER} 0 1 _PACKAGE_HEADER_NAME)
set(_PACKAGE_HEADER_NAME ${_PACKAGE_HEADER_NAME}${_PACKAGE_HEADER_TAIL})
if(CPACK_RPM_PACKAGE_DEBUG)
  message(CPackRPM:Debug: User defined ${_PACKAGE_HEADER_NAME}:\n
${CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER}_TMP})
endif()
set(TMP_RPM_${_RPM_SPEC_HEADER} ${_PACKAGE_HEADER_NAME}:
${CPACK_RPM_PACKAGE_${_RPM_SPEC_HEADER}_TMP})
  else()
# Do not forget to unset previously set header (from previous component)
unset(TMP_RPM_${_RPM_SPEC_HEADER})
  endif()


and I expect that it affects every variable which is looped over and hits that
code:


foreach(_RPM_SPEC_HEADER URL REQUIRES SUGGESTS PROVIDES OBSOLETES PREFIX
CONFLICTS AUTOPROV AUTOREQ AUTOREQPROV)


but I've only tested it with CPACK_RPM_PACKAGE_AUTOREQPROV. I've also only
tested it with a library target.

Steps to Reproduce: 
1. Use set(CPACK_RPM_PACKAGE_AUTOREQPROV 0) or set(CPACK_RPM_PACKAGE_AUTOREQPROV
no) as part of setting up cpack for generating RPMs in cmake.

2. Use make package to generate the RPM.

3. Run rpm -qRp filename.rpm on your rpm, and it will print out the list of
stuff in the Required field of the RPM. It should have a very short list of
items with no .so files included.

Instead, it lists all of the .so files that your program or library requires;
stuff like

libc.so.6()(64bit)  
libc.so.6(GLIBC_2.2.5)(64bit)  
libc.so.6(GLIBC_2.3)(64bit)  
libc.so.6(GLIBC_2.7)(64bit)
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-02-07 19:15 Jonathan M DavisNew Issue
==

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0013899]: Documentation for RPM CPack generator is missing a number of the variables that it supports

2013-02-07 Thread Mantis Bug Tracker


The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=13899 
== 
Reported By:Jonathan M Davis
Assigned To:
== 
Project:CMake
Issue ID:   13899
Category:   Documentation
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-02-07 19:23 EST
Last Modified:  2013-02-07 19:23 EST
== 
Summary:Documentation for RPM CPack generator is missing a
number of the variables that it supports
Description: 
I don't know if this report is entirely appropriate, since it relates to the
wiki rather than the official documentation, but that's the only documentation
for the CPack RPM generator that I'm aware of. In any case, the page
http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#RPM_.28Unix_Only.29 lists
the RPM-specific variables that CPack's RPM generator supports, and it's missing
several of them. In particular, these variables are missing

CPACK_RPM_PACKAGE_URL
CPACK_RPM_PACKAGE_SUGGESTS
CPACK_RPM_PACKAGE_OBSOLETES
CPACK_RPM_PACKAGE_PREFIX
CPACK_RPM_PACKAGE_CONFLICTS
CPACK_RPM_PACKAGE_AUTOPROV
CPACK_RPM_PACKAGE_AUTOREQ
CPACK_RPM_PACKAGE_AUTOREQPROV

They need to be documented. It took me quite a while to figure out how to figure
out that CPACK_RPM_PACKAGE_AUTOREQPROV even existed, let alone how to set it
(bug# 13898 made that harder than it should have been). You shouldn't need to
read CPackRPM.cmake to figure out how to use CPack's RPM generator.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-02-07 19:23 Jonathan M DavisNew Issue
==

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [CMake] CPack: Packaging debug and release configurations in a single zip

2013-02-07 Thread Yngve Inntjore Levinsen

Did you try to create two targets and add per-target compile flags?

Something along the lines of
add_library(mylib_rel ${sources})
add_library(mylib_dbg ${sources})
set_target_properties(mylib_rel PROPERTIES COMPILE_FLAGS -O3)
set_target_properties(mylib_dbg PROPERTIES COMPILE_FLAGS -O0 -g)

Not entirely sure if COMPILE_FLAGS is a valid property of targets
though, but I would imagine there is a solution which looks similar to
this..

Cheers,
Yngve

On 02/06/2013 08:09 PM, Patrick Johnmeyer wrote:
 I have looked through the CMake wikis and several mailing list threads
 that the following google search returned, and I have not found a
 definitive answer to my question.

 [site:www.cmake.org/pipermail/cmake
 http://www.cmake.org/pipermail/cmake CPack multiple configurations
 in one package]

 My team delivers debug and release libraries, built under Visual
 Studio. We would like to package the debug and release libraries in a
 single zip file. However, I can only figure out how to get CPack to
 generate the zip for one configuration at a time. I could merge the
 two zip files after the fact, but it seems to me that there must be an
 easy way to get CPack to do this. Is there?

 Regards,
 pj


 --

 Powered by www.kitware.com

 Visit other Kitware open-source projects at 
 http://www.kitware.com/opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at: 
 http://www.cmake.org/Wiki/CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack: Packaging debug and release configurations in a single zip

2013-02-07 Thread Patrick Johnmeyer

On Thu, Feb 7, 2013 at 3:12 AM, Yngve Inntjore Levinsen 
yngve.levin...@gmail.com wrote:

  Did you try to create two targets and add per-target compile flags?


What you suggest is replacing configurations with targets. That may be
possible, but runs counter to how CMake natively works. I feel like I
would be fighting the tool to do it this way.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack: Packaging debug and release configurations in a single zip

2013-02-07 Thread Ansis Māliņš

How about something like this:

if(${CMAKE_BUILD_TYPE STREQUAL DebugAndRelease)
include(ExternalProject)
ExternalProject_Add(MEDEBUG
CMAKE_FLAGS -DCMAKE_BUILD_TYPE Debug)
ExternalProject_Add(MERELEASE
CMAKE_FLAGS -DCMAKE_BUILD_TYPE Release)
install(FILES ...)
#etc, etc.
return()
endif()
# the usual build code comes after

That is, add a new special build type, that, when built, makes the project
just build itself twice as an external project, package it up, and exit
before the normal build code.
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack: Packaging debug and release configurations in a single zip

2013-02-07 Thread Yngve Inntjore Levinsen

Hi,

I think you are fighting the tool in any case, because you are asking to
build multiple configurations in one build folder (?). Normally you
would create one build folder per configuration.. Which I guess is what
you are doing today.

Instead of specifying the compile flags manually you can instead use the
variables ${CMAKE_C_FLAGS_RELEASE} and ${CMAKE_C_FLAGS_DEBUG},
and you could set it so it only builds the second target based on an option:

option(BUILD_BOTH_LIBVERSIONS Build both debug and optimized library OFF)

if(BUILD_BOTH_LIBVERSIONS)
add_library(...)
set_target_properties(...)
set_target_properties(...)
install(...)
endif()

Cheers,
Yngve

On 02/07/2013 07:26 PM, Patrick Johnmeyer wrote:
 On Thu, Feb 7, 2013 at 3:12 AM, Yngve Inntjore Levinsen
 yngve.levin...@gmail.com mailto:yngve.levin...@gmail.com wrote:

 Did you try to create two targets and add per-target compile flags?


 What you suggest is replacing configurations with targets. That may be
 possible, but runs counter to how CMake natively works. I feel like I
 would be fighting the tool to do it this way.


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Visual Studio makefile project output

2013-02-07 Thread Bill Hoffman


On 2/6/2013 6:00 PM, Theo Berkau wrote:

Hello,

I've been trying to setup a cross-compiled project using cmake and so
far everything's working fine using Unix Makefiles generator, etc. Now
I know generating for visual studio generally doesn't work under a cross
compiling setup, but I was wondering if it's possible to set up cmake to
output a visual studio makefile project(as opposed to what NMake
Makefiles generates).

Yes, it is possible to create Unix Makefiles for windows.

This blog post might help you:
http://www.kitware.com/blog/home/post/434

See the section on Windows.

-Bill

--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack: Packaging debug and release configurations in a single zip

2013-02-07 Thread Jean-Christophe Fillion-Robin

The approach suggested by Ansis looks interesting. Instead of using
install(FILES ...), you could use CPACK_INSTALL_CMAKE_PROJECTS [1][2]. For
an example, see [3] and [4]

[1]
http://www.cmake.org/cmake/help/v2.8.8/cpack.html#variable:CPACK_INSTALL_CMAKE_PROJECTS
[2] http://www.cmake.org/Wiki/CMake:CPackConfiguration
[3]
https://github.com/Slicer/Slicer/blob/master/CMake/SlicerCPack.cmake#L17-36
[4]
https://github.com/Slicer/Slicer/blob/master/CMake/SlicerBlockInstallCMakeProjects.cmake



if(${CMAKE_BUILD_TYPE STREQUAL DebugAndRelease)
include(ExternalProject)
ExternalProject_Add(MEDEBUG
CMAKE_FLAGS -DCMAKE_BUILD_TYPE Debug)
ExternalProject_Add(MERELEASE
CMAKE_FLAGS -DCMAKE_BUILD_TYPE Release)

set(CPACK_INSTALL_CMAKE_PROJECTS  )  # 

#etc, etc.
return()
endif()

Hth
Jc


On Thu, Feb 7, 2013 at 1:41 PM, Yngve Inntjore Levinsen 
yngve.levin...@gmail.com wrote:

  Hi,

 I think you are fighting the tool in any case, because you are asking to
 build multiple configurations in one build folder (?). Normally you would
 create one build folder per configuration.. Which I guess is what you are
 doing today.

 Instead of specifying the compile flags manually you can instead use the
 variables ${CMAKE_C_FLAGS_RELEASE} and ${CMAKE_C_FLAGS_DEBUG},
 and you could set it so it only builds the second target based on an
 option:

 option(BUILD_BOTH_LIBVERSIONS Build both debug and optimized library OFF)

 if(BUILD_BOTH_LIBVERSIONS)
 add_library(...)
 set_target_properties(...)
 set_target_properties(...)
 install(...)
 endif()

 Cheers,
 Yngve


 On 02/07/2013 07:26 PM, Patrick Johnmeyer wrote:

 On Thu, Feb 7, 2013 at 3:12 AM, Yngve Inntjore Levinsen 
 yngve.levin...@gmail.com wrote:

  Did you try to create two targets and add per-target compile flags?


  What you suggest is replacing configurations with targets. That may be
 possible, but runs counter to how CMake natively works. I feel like I
 would be fighting the tool to do it this way.



 --

 Powered by www.kitware.com

 Visit other Kitware open-source projects at
 http://www.kitware.com/opensource/opensource.html

 Please keep messages on-topic and check the CMake FAQ at:
 http://www.cmake.org/Wiki/CMake_FAQ

 Follow this link to subscribe/unsubscribe:
 http://www.cmake.org/mailman/listinfo/cmake




-- 
+1 919 869 8849
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack: Packaging debug and release configurations in a single zip

2013-02-07 Thread Patrick Johnmeyer

On Thu, Feb 7, 2013 at 12:41 PM, Yngve Inntjore Levinsen 
yngve.levin...@gmail.com wrote:

 I think you are fighting the tool in any case, because you are asking to
 build multiple configurations in one build folder (?). Normally you would
 create one build folder per configuration.. Which I guess is what you are
 doing today.


No, the Visual Studio generator is not a *single-configuration
generator*. all
configurations are bundled into the single generated solution file. This is
the standard behavior of CMake under basic usage.

Your solution using ExternalProject looks promising, though, I will try
this out. Thanks!
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] CPack: Packaging debug and release configurations in a single zip

2013-02-07 Thread Clinton Stimpson

On Wednesday, February 06, 2013 01:09:20 PM Patrick Johnmeyer wrote:
 I have looked through the CMake wikis and several mailing list threads that
 the following google search returned, and I have not found a definitive
 answer to my question.
 
 [site:www.cmake.org/pipermail/cmake CPack multiple configurations in one
 package]
 
 My team delivers debug and release libraries, built under Visual Studio. We
 would like to package the debug and release libraries in a single zip file.
 However, I can only figure out how to get CPack to generate the zip for one
 configuration at a time. I could merge the two zip files after the fact,
 but it seems to me that there must be an easy way to get CPack to do this.
 Is there?
 
 Regards,
 pj

Here's one way I've done it.

option(CREATE_MULTI_CONFIG_PACKAGE Enable creating a multi-config package with 
both debug and release (doubles compile time) OFF)


if(CREATE_MULTI_CONFIG_PACKAGE)

  set up a secondary build tree at ${CMAKE_BINARY_DIR}/SecondaryBuildTree, 
passing cmake options from here down to the secondary tree to make them match

  I use execute_process to run cmake on the second tree and pass options down 
(which compiler, and project specific settings that the user can modify for the 
primary build tree).

add a custom target to build the second build tree by running cmake --build


  # tell cpack to install both projects
  set(CPACK_INSTALL_CMAKE_PROJECTS 
# self project
  ${CMAKE_BINARY_DIR};${CMAKE_PROJECT_NAME};ALL;/
# other config project
  ${CMAKE_BINARY_DIR}/SecondaryBuildTree;${CMAKE_PROJECT_NAME};ALL;/
  )
endif()


-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[CMake] Building Mac OSX .apps for Sys 10.6 and 10.8 with Cmake using 10.7.5 on the command line

2013-02-07 Thread Ed

Hello:
I am trying to build an app to be compatible with Mac OSX systems 10.6, 10.7, 
and 10.8 using the command line with cmake.  I have successfully built it for 
10.7.5, now I would like to expand this app to be compatible with 10.6 and 10.8 
is this possible?
This is the command I am issuing to cmake:
cmake -DCMAKE_OSX_64=ON -DCMAKE_C_COMPILER=/usr/bin/gcc 
-DCMAKE_CXX_COMPILER=/usr/bin/g++ ..

Could anyone help me to build this app to be compatible with the other two 
system?

TIA,
Freddie 
--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] Building Mac OSX .apps for Sys 10.6 and 10.8 with Cmake using 10.7.5 on the command line

2013-02-07 Thread Sean McBride

On Thu, 7 Feb 2013 17:05:55 -0800, Ed said:

I am trying to build an app to be compatible with Mac OSX systems 10.6,
10.7, and 10.8 using the command line with cmake.  I have successfully
built it for 10.7.5, now I would like to expand this app to be
compatible with 10.6 and 10.8 is this possible?
This is the command I am issuing to cmake:
cmake -DCMAKE_OSX_64=ON -DCMAKE_C_COMPILER=/usr/bin/gcc -
DCMAKE_CXX_COMPILER=/usr/bin/g++ ..

Could anyone help me to build this app to be compatible with the other
two system?

The most important thing is to set the deployment target to 10.6.  See 
CMAKE_OSX_DEPLOYMENT_TARGET.  If you want to support both 32 and 64 bit CPUs, 
you should also set the architectures, see CMAKE_OSX_ARCHITECTURES.

Cheers,

-- 

Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com 
Mac Software Developer  Montréal, Québec, Canada


--

Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1967-gb6947b7

2013-02-07 Thread Stephen Kelly

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  b6947b77d5109c192cb2c64b061fb0cb771882f8 (commit)
   via  2da342e70df8b1121f3a9364641f8e81c6382c63 (commit)
   via  65d1cab7b26734759f6e29deb69dbebc2f3f6fef (commit)
   via  114e0533907f06914372bee96f54cb586fb3476c (commit)
   via  e0e9642fa3595c8b35bc194031933d2706e7ed6e (commit)
   via  52c9f98d7c4e092e6294e3996454155879da81e0 (commit)
   via  5d590aa7eb3a3b481148a02770dc83c7926f0b0b (commit)
  from  2c8c851fd53d0955000364060f9c41cf0b5f3937 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b6947b77d5109c192cb2c64b061fb0cb771882f8
commit b6947b77d5109c192cb2c64b061fb0cb771882f8
Merge: 2c8c851 2da342e
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 04:02:35 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 7 04:02:35 2013 -0500

Merge topic 'minor-fixes' into next

2da342e Fix generation of COMPILE_DEFINITIONS in DependInfo.cmake.
65d1cab Ensure type specific compatible interface properties do not 
intersect.
114e053 The COMPATIBLE_INTERFACE does not affect the target it is set on.
e0e9642 Test printing origin of include dirs from tll().
52c9f98 De-duplicate validation of genex target names.
5d590aa Deduplicate the isGeneratorExpression method.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2da342e70df8b1121f3a9364641f8e81c6382c63
commit 2da342e70df8b1121f3a9364641f8e81c6382c63
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 01:49:17 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Feb 7 10:01:38 2013 +0100

Fix generation of COMPILE_DEFINITIONS in DependInfo.cmake.

As INTERFACE_COMPILE_DEFINITIONS are now possible, we can have
situations like this:

 add_library(foo ...)
 add_library(bar ...)
 target_link_libraries(foo bar)

 target_compile_definitions(bar INTERFACE SOME_DEF)

The INTERFACE_COMPILE_DEFINITIONS of bar determine how foo should be
compiled, and if they change, foo should be rebuilt.

Additionally, as of commit d1446ca7 (Append the COMPILE_DEFINITIONS
from the Makefile to all targets., 2012-09-17), we don't need to
read definitions from the makefile if we read them from the target,
so also de-duplicate the cached info.

The DependInfo for INTERFACE_INCLUDE_DIRECTORIES is already handled
correctly.

diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx 
b/Source/cmLocalUnixMakefileGenerator3.cxx
index d629e71..f6ab0d0 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -1961,34 +1961,17 @@ void cmLocalUnixMakefileGenerator3
 }
 
   // Build a list of preprocessor definitions for the target.
-  std::vectorstd::string defines;
-  {
-  std::string defPropName = COMPILE_DEFINITIONS_;
-  defPropName += cmSystemTools::UpperCase(this-ConfigurationName);
-  if(const char* ddefs = this-Makefile-GetProperty(COMPILE_DEFINITIONS))
-{
-cmSystemTools::ExpandListArgument(ddefs, defines);
-}
-  if(const char* cdefs = target.GetProperty(COMPILE_DEFINITIONS))
-{
-cmSystemTools::ExpandListArgument(cdefs, defines);
-}
-  if(const char* dcdefs = this-Makefile-GetProperty(defPropName.c_str()))
-{
-cmSystemTools::ExpandListArgument(dcdefs, defines);
-}
-  if(const char* ccdefs = target.GetProperty(defPropName.c_str()))
-{
-cmSystemTools::ExpandListArgument(ccdefs, defines);
-}
-  }
+  std::setstd::string defines;
+  this-AppendDefines(defines, target.GetCompileDefinitions());
+  this-AppendDefines(defines, target.GetCompileDefinitions(
+this-ConfigurationName.c_str()));
   if(!defines.empty())
 {
 cmakefileStream
\n
# Preprocessor definitions for this target.\n
SET(CMAKE_TARGET_DEFINITIONS\n;
-for(std::vectorstd::string::const_iterator di = defines.begin();
+for(std::setstd::string::const_iterator di = defines.begin();
 di != defines.end(); ++di)
   {
   cmakefileStream

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=65d1cab7b26734759f6e29deb69dbebc2f3f6fef
commit 65d1cab7b26734759f6e29deb69dbebc2f3f6fef
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 00:47:31 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Feb 7 10:01:38 2013 +0100

Ensure type specific compatible interface properties do not intersect.

Before, the boolean version would always win, and the string one would

[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1975-gac37dfb

2013-02-07 Thread Stephen Kelly

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  ac37dfb6628e9c43da6912885c255e3bef216257 (commit)
   via  b5f8a0c3fb2378d9deeb7ba7a3d03f9210be8d30 (commit)
   via  f333f14374afd3774e3d48e2ede7e2692e4bfa63 (commit)
   via  431c5a60fc295329bdd36c21ac6a956b9c84d131 (commit)
   via  611c7798202afec651d07ddabfd70688dee1432d (commit)
   via  13965a7b3d51c0deba29ae566ff09165527f07d4 (commit)
   via  2e04459b56a63eb52af17ab55136661846d7d5f2 (commit)
   via  1714c27a74c1616e5998a1a51fe42848a1f1c389 (commit)
  from  b6947b77d5109c192cb2c64b061fb0cb771882f8 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ac37dfb6628e9c43da6912885c255e3bef216257
commit ac37dfb6628e9c43da6912885c255e3bef216257
Merge: b6947b7 b5f8a0c
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 04:07:38 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 7 04:07:38 2013 -0500

Merge topic 'minor-fixes' into next

b5f8a0c Fix generation of COMPILE_DEFINITIONS in DependInfo.cmake.
f333f14 Ensure type specific compatible interface properties do not 
intersect.
431c5a6 The COMPATIBLE_INTERFACE does not affect the target it is set on.
611c779 Test printing origin of include dirs from tll().
13965a7 De-duplicate validation of genex target names.
2e04459 Deduplicate the isGeneratorExpression method.
1714c27 Process generator expressions for 'system' include directories.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b5f8a0c3fb2378d9deeb7ba7a3d03f9210be8d30
commit b5f8a0c3fb2378d9deeb7ba7a3d03f9210be8d30
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 01:49:17 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Feb 7 10:07:19 2013 +0100

Fix generation of COMPILE_DEFINITIONS in DependInfo.cmake.

As INTERFACE_COMPILE_DEFINITIONS are now possible, we can have
situations like this:

 add_library(foo ...)
 add_library(bar ...)
 target_link_libraries(foo bar)

 target_compile_definitions(bar INTERFACE SOME_DEF)

The INTERFACE_COMPILE_DEFINITIONS of bar determine how foo should be
compiled, and if they change, foo should be rebuilt.

Additionally, as of commit d1446ca7 (Append the COMPILE_DEFINITIONS
from the Makefile to all targets., 2012-09-17), we don't need to
read definitions from the makefile if we read them from the target,
so also de-duplicate the cached info.

The DependInfo for INTERFACE_INCLUDE_DIRECTORIES is already handled
correctly.

diff --git a/Source/cmLocalUnixMakefileGenerator3.cxx 
b/Source/cmLocalUnixMakefileGenerator3.cxx
index d629e71..f6ab0d0 100644
--- a/Source/cmLocalUnixMakefileGenerator3.cxx
+++ b/Source/cmLocalUnixMakefileGenerator3.cxx
@@ -1961,34 +1961,17 @@ void cmLocalUnixMakefileGenerator3
 }
 
   // Build a list of preprocessor definitions for the target.
-  std::vectorstd::string defines;
-  {
-  std::string defPropName = COMPILE_DEFINITIONS_;
-  defPropName += cmSystemTools::UpperCase(this-ConfigurationName);
-  if(const char* ddefs = this-Makefile-GetProperty(COMPILE_DEFINITIONS))
-{
-cmSystemTools::ExpandListArgument(ddefs, defines);
-}
-  if(const char* cdefs = target.GetProperty(COMPILE_DEFINITIONS))
-{
-cmSystemTools::ExpandListArgument(cdefs, defines);
-}
-  if(const char* dcdefs = this-Makefile-GetProperty(defPropName.c_str()))
-{
-cmSystemTools::ExpandListArgument(dcdefs, defines);
-}
-  if(const char* ccdefs = target.GetProperty(defPropName.c_str()))
-{
-cmSystemTools::ExpandListArgument(ccdefs, defines);
-}
-  }
+  std::setstd::string defines;
+  this-AppendDefines(defines, target.GetCompileDefinitions());
+  this-AppendDefines(defines, target.GetCompileDefinitions(
+this-ConfigurationName.c_str()));
   if(!defines.empty())
 {
 cmakefileStream
\n
# Preprocessor definitions for this target.\n
SET(CMAKE_TARGET_DEFINITIONS\n;
-for(std::vectorstd::string::const_iterator di = defines.begin();
+for(std::setstd::string::const_iterator di = defines.begin();
 di != defines.end(); ++di)
   {
   cmakefileStream

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f333f14374afd3774e3d48e2ede7e2692e4bfa63
commit f333f14374afd3774e3d48e2ede7e2692e4bfa63
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 00:47:31 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Feb 7 10:07:19 2013 +0100

Ensure type

[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1984-g03df039

2013-02-07 Thread Brad King

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  03df039502924398fe51ccd492ef4a5c93c86b71 (commit)
   via  7df291fb6e6971f60cc7b338bcaa81069ed11757 (commit)
   via  9d66f74335a09019644c7b82af0860da439fce87 (commit)
   via  bc75f4c4c606412429e97d12ef1d550e7096cdfc (commit)
  from  622894b34fd13b098c7b2a5b7b7c4b3d0b770c31 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=03df039502924398fe51ccd492ef4a5c93c86b71
commit 03df039502924398fe51ccd492ef4a5c93c86b71
Merge: 622894b 7df291f
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Feb 7 10:12:46 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 7 10:12:46 2013 -0500

Merge topic 'update-kwsys' into next

7df291f Merge branch 'upstream-kwsys' into update-kwsys
9d66f74 KWSys 2013-02-05 (5c34ed2e)
bc75f4c CMake Nightly Date Stamp


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7df291fb6e6971f60cc7b338bcaa81069ed11757
commit 7df291fb6e6971f60cc7b338bcaa81069ed11757
Merge: bc75f4c 9d66f74
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Feb 7 08:34:56 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Feb 7 08:34:56 2013 -0500

Merge branch 'upstream-kwsys' into update-kwsys


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9d66f74335a09019644c7b82af0860da439fce87
commit 9d66f74335a09019644c7b82af0860da439fce87
Author: KWSys Robot kwro...@kitware.com
AuthorDate: Tue Feb 5 08:37:35 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Feb 7 08:34:52 2013 -0500

KWSys 2013-02-05 (5c34ed2e)

Extract upstream KWSys using the following shell commands.

$ git archive --prefix=upstream-kwsys/ 5c34ed2e | tar x
$ git shortlog --no-merges --abbrev=8 --format='%h %s' 5b0d1bd9..5c34ed2e
Brad King (1):
  5c34ed2e SystemTools: Do not abort with no current directory

Change-Id: Id054017eac2bf10c71ca721df48298cdff2bea82

diff --git a/SystemTools.cxx b/SystemTools.cxx
index 881c49a..22bf193 100644
--- a/SystemTools.cxx
+++ b/SystemTools.cxx
@@ -196,18 +196,16 @@ inline int Rmdir(const char* dir)
 }
 inline const char* Getcwd(char* buf, unsigned int len)
 {
-  const char* ret = _getcwd(buf, len);
-  if(!ret)
+  if(const char* ret = _getcwd(buf, len))
 {
-fprintf(stderr, No current working directory.\n);
-abort();
-}
-  // make sure the drive letter is capital
-  if(strlen(buf)  1  buf[1] == ':')
-{
-buf[0] = toupper(buf[0]);
+// make sure the drive letter is capital
+if(strlen(buf)  1  buf[1] == ':')
+  {
+  buf[0] = toupper(buf[0]);
+  }
+return ret;
 }
-  return ret;
+  return 0;
 }
 inline int Chdir(const char* dir)
 {
@@ -245,13 +243,7 @@ inline int Rmdir(const char* dir)
 }
 inline const char* Getcwd(char* buf, unsigned int len)
 {
-  const char* ret = getcwd(buf, len);
-  if(!ret)
-{
-fprintf(stderr, No current working directory\n);
-abort();
-}
-  return ret;
+  return getcwd(buf, len);
 }
 
 inline int Chdir(const char* dir)
@@ -3089,7 +3081,7 @@ kwsys_stl::string SystemTools::CollapseFullPath(const 
char* in_path,
 }
   else
 {
-// ??
+base_components.push_back();
 }
   }
 

---

Summary of changes:
 Source/CMakeVersion.cmake|2 +-
 Source/kwsys/SystemTools.cxx |   28 ++--
 2 files changed, 11 insertions(+), 19 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v2.8.10.2-1999-gc53d0f1

2013-02-07 Thread Stephen Kelly

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  c53d0f18a8fb38c2d38c113c7341b2e95691eba6 (commit)
   via  d4e5c6787c40e27394c336730f59d878a81d1991 (commit)
   via  1fb545ad3a8f6d263c9f01300bce978e81b6fe8c (commit)
   via  57175d559ee2bdd56c360a3b45aacf13b15b9270 (commit)
   via  4cf161a5e7af6f32d76263ac751600577e4d7bd3 (commit)
   via  3a298c0bf4e3e86f4705b9255bf032cf70d5cadb (commit)
   via  655e98bf7149eb3757a0587409076326edeb9c04 (commit)
   via  46e28960a58a25bbf0124b6ab95eda24cc4fe1a4 (commit)
   via  5f926a58026c3c750738e26975834b662fc85727 (commit)
   via  7c0ec75cfa6860b53036fe46c005b84277cdbc24 (commit)
   via  92e98dd909bd399f508ff7c2f9657095ddc766cc (commit)
  from  911b65c2fbab85bff5f3425bbeb70a1d74c63981 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c53d0f18a8fb38c2d38c113c7341b2e95691eba6
commit c53d0f18a8fb38c2d38c113c7341b2e95691eba6
Merge: 911b65c d4e5c67
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 10:21:37 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 7 10:21:37 2013 -0500

Merge topic 'minor-fixes' into next

d4e5c67 Don't keep track of content determined by target property values.
1fb545a Move a special case for PIC from the genex to the cmTarget code.
57175d5 Only use early evaluation termination for transitive properties.
4cf161a Fix determination of evaluating link libraries.
3a298c0 Fix generation of COMPILE_DEFINITIONS in DependInfo.cmake.
655e98b Ensure type specific compatible interface properties do not 
intersect.
46e2896 The COMPATIBLE_INTERFACE does not affect the target it is set on.
5f926a5 Test printing origin of include dirs from tll().
7c0ec75 De-duplicate validation of genex target names.
92e98dd Deduplicate the isGeneratorExpression method.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d4e5c6787c40e27394c336730f59d878a81d1991
commit d4e5c6787c40e27394c336730f59d878a81d1991
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 13:04:46 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Feb 7 16:21:09 2013 +0100

Don't keep track of content determined by target property values.

This tracking was added during the development of commit 042ecf04
(Add API to calculate link-interface-dependent bool properties
or error., 2013-01-06), but was never used.

It was not necessary to use the content because what is really
useful in that logic is to determine if a property has been implied
to be null by appearing in a LINK_LIBRARIES genex.

I think the motivating usecase for developing the feature of
keeping track of the targets relevant to a property was that I
thought it would  make it possible to allow requiring granular
compatibility of interface properties only for targets which
depended on the interface property. Eg:

 add_library(foo ...)
 add_library(bar ...)

 add_executable(user ...)
 # Read the INTERFACE_POSITION_INDEPENDENT_CODE from bar, but not
 # from foo:
 target_link_libraries(user foo 
$$TARGET_PROPERTY:POSTITION_INDEPENDENT_CODE:bar)

This obviously doesn't make sense. We require that INTERFACE
properties are consistent across all linked targets instead.

diff --git a/Source/cmGeneratorExpression.cxx b/Source/cmGeneratorExpression.cxx
index 60bf179..5d162fe 100644
--- a/Source/cmGeneratorExpression.cxx
+++ b/Source/cmGeneratorExpression.cxx
@@ -95,14 +95,13 @@ const char *cmCompiledGeneratorExpression::Evaluate(
 
   for ( ; it != end; ++it)
 {
-const std::string result = (*it)-Evaluate(context, dagChecker);
-this-Output += result;
+this-Output += (*it)-Evaluate(context, dagChecker);
 
 for(std::setcmStdString::const_iterator
   p = context.SeenTargetProperties.begin();
   p != context.SeenTargetProperties.end(); ++p)
   {
-  this-SeenTargetProperties[*p] += result + ;;
+  this-SeenTargetProperties.insert(*p);
   }
 if (context.HadError)
   {
diff --git a/Source/cmGeneratorExpression.h b/Source/cmGeneratorExpression.h
index 4eab2dd..489b052 100644
--- a/Source/cmGeneratorExpression.h
+++ b/Source/cmGeneratorExpression.h
@@ -90,7 +90,7 @@ public:
   std::setcmTarget* const GetTargets() const
 { return this-Targets; }
 
-  std::mapcmStdString, cmStdString const GetSeenTargetProperties() const
+  std::setcmStdString const GetSeenTargetProperties() const
 { return this-SeenTargetProperties; }

[Cmake-commits] CMake branch, next, updated. v2.8.10.2-2011-g910ad89

2013-02-07 Thread Stephen Kelly

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  910ad89f3c556f8902e3206a620b9c867b6dcb39 (commit)
   via  3851e0a2ca954a457ce93d52f4c727e18cb64c73 (commit)
   via  fecede0d9012f78470778cb049b2ab0231b4dcb7 (commit)
  from  39a1e2569c3b45552927e83c35ace90dc84c98d2 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=910ad89f3c556f8902e3206a620b9c867b6dcb39
commit 910ad89f3c556f8902e3206a620b9c867b6dcb39
Merge: 39a1e25 3851e0a
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 13:40:42 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 7 13:40:42 2013 -0500

Merge topic 'minor-fixes' into next

3851e0a Ensure that the build interface includes have been added.
fecede0 Only append build interface include dirs to particular targets.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3851e0a2ca954a457ce93d52f4c727e18cb64c73
commit 3851e0a2ca954a457ce93d52f4c727e18cb64c73
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 19:35:00 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Feb 7 19:38:35 2013 +0100

Ensure that the build interface includes have been added.

This also means that we don't need to invoke AppendBuildInterfaceIncludes
in the GlobalGenerator.

diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index f7eff21..b8e1668 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -938,11 +938,6 @@ void cmGlobalGenerator::Generate()
   (*targets)[tit-first] = tit-second;
   (*targets)[tit-first].SetMakefile(mf);
   }
-
-for ( tit = targets-begin(); tit != targets-end(); ++ tit )
-  {
-tit-second.AppendBuildInterfaceIncludes();
-  }
 }
 
   // Add generator specific helper commands
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 7497070..378c7b5 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2766,6 +2766,7 @@ std::vectorstd::string 
cmTarget::GetIncludeDirectories(const char *config)
   this-GetName(),
   INCLUDE_DIRECTORIES, 0, 0);
 
+  this-AppendBuildInterfaceIncludes();
 
   std::vectorstd::string debugProperties;
   const char *debugProp =

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fecede0d9012f78470778cb049b2ab0231b4dcb7
commit fecede0d9012f78470778cb049b2ab0231b4dcb7
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 19:31:23 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Feb 7 19:33:24 2013 +0100

Only append build interface include dirs to particular targets.

We shouldn't set the property on all custom targets.

diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx
index 08b3ef1..93a3ae0 100644
--- a/Source/cmDocumentVariables.cxx
+++ b/Source/cmDocumentVariables.cxx
@@ -1150,9 +1150,10 @@ void cmDocumentVariables::DefineVariables(cmake* cm)
 (CMAKE_BUILD_INTERFACE_INCLUDES, cmProperty::VARIABLE,
  Automatically add the current source- and build directories 
  to the INTERFACE_INCLUDE_DIRECTORIES.,
- If this variable is enabled, CMake automatically adds for each 
- target ${CMAKE_CURRENT_SOURCE_DIR} and ${CMAKE_CURRENT_BINARY_DIR} 
- to the INTERFACE_INCLUDE_DIRECTORIES.
+ If this variable is enabled, CMake automatically adds for each shared 
+ library target, module target and executable target, 
+ ${CMAKE_CURRENT_SOURCE_DIR} and ${CMAKE_CURRENT_BINARY_DIR} to the 
+ INTERFACE_INCLUDE_DIRECTORIES.
  By default CMAKE_BUILD_INTERFACE_INCLUDES is OFF.,
  false,
  Variables that Control the Build);
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index f55999f..7497070 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2714,6 +2714,12 @@ void cmTarget::AppendProperty(const char* prop, const 
char* value,
 //
 void cmTarget::AppendBuildInterfaceIncludes()
 {
+  if(this-GetType() != cmTarget::SHARED_LIBRARY 
+ this-GetType() != cmTarget::MODULE_LIBRARY 
+ !this-IsExecutableWithExports())
+{
+return;
+}
   if (this-BuildInterfaceIncludesAppended)
 {
 return;

---

Summary of changes:
 Source/cmDocumentVariables.cxx |7 ---
 Source/cmGlobalGenerator.cxx   |5 -
 Source/cmTarget.cxx|7 +++
 3 files changed, 11 insertions(+), 8

[Cmake-commits] CMake branch, next, updated. v2.8.10.2-2013-g3efc388

2013-02-07 Thread Brad King

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  3efc38828749d34c1f2e3c87a031db3b85dece14 (commit)
   via  fe664b5d1d4c00021197adf504c5f8de81f7cf5a (commit)
  from  910ad89f3c556f8902e3206a620b9c867b6dcb39 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3efc38828749d34c1f2e3c87a031db3b85dece14
commit 3efc38828749d34c1f2e3c87a031db3b85dece14
Merge: 910ad89 fe664b5
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Feb 7 15:05:40 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 7 15:05:40 2013 -0500

Merge topic 'CMAKE_CL_64-CXX' into next

fe664b5 MSVC: Fix CMAKE_CL_64 in CXX-only projects (#13896)


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe664b5d1d4c00021197adf504c5f8de81f7cf5a
commit fe664b5d1d4c00021197adf504c5f8de81f7cf5a
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Feb 7 15:04:06 2013 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Feb 7 15:04:06 2013 -0500

MSVC: Fix CMAKE_CL_64 in CXX-only projects (#13896)

When CXX is enabled without C then MSVC_CXX_ARCHITECTURE_ID is set
instead but not MSVC_C_ARCHITECTURE_ID.  Test both.

diff --git a/Modules/Platform/Windows-MSVC.cmake 
b/Modules/Platform/Windows-MSVC.cmake
index 3a38d8f..f9df6d8 100644
--- a/Modules/Platform/Windows-MSVC.cmake
+++ b/Modules/Platform/Windows-MSVC.cmake
@@ -107,7 +107,7 @@ if(NOT MSVC_VERSION)
   endif()
 endif()
 
-if(MSVC_C_ARCHITECTURE_ID MATCHES 64)
+if(MSVC_C_ARCHITECTURE_ID MATCHES 64 OR MSVC_CXX_ARCHITECTURE_ID MATCHES 64)
   set(CMAKE_CL_64 1)
 else()
   set(CMAKE_CL_64 0)

---

Summary of changes:
 Modules/Platform/Windows-MSVC.cmake |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v2.8.10.2-2016-g5f456de

2013-02-07 Thread Stephen Kelly

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  5f456ded1e6426c57f82306f36a517875898a68a (commit)
   via  26147183b93dcf355815a1a0e39413453000d2a9 (commit)
   via  51bb509b52b51983b5e8c48f08cc23c7faaeb2f5 (commit)
  from  3efc38828749d34c1f2e3c87a031db3b85dece14 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5f456ded1e6426c57f82306f36a517875898a68a
commit 5f456ded1e6426c57f82306f36a517875898a68a
Merge: 3efc388 2614718
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 15:57:14 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 7 15:57:14 2013 -0500

Merge topic 'minor-fixes' into next

2614718 Restore appending build interface includes at generate time.
51bb509 INTERFACE_INCLUDE_DIRECTORIES should also be populated for static 
libs.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=26147183b93dcf355815a1a0e39413453000d2a9
commit 26147183b93dcf355815a1a0e39413453000d2a9
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 21:56:08 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Feb 7 21:56:08 2013 +0100

Restore appending build interface includes at generate time.

diff --git a/Source/cmGlobalGenerator.cxx b/Source/cmGlobalGenerator.cxx
index b8e1668..f7eff21 100644
--- a/Source/cmGlobalGenerator.cxx
+++ b/Source/cmGlobalGenerator.cxx
@@ -938,6 +938,11 @@ void cmGlobalGenerator::Generate()
   (*targets)[tit-first] = tit-second;
   (*targets)[tit-first].SetMakefile(mf);
   }
+
+for ( tit = targets-begin(); tit != targets-end(); ++ tit )
+  {
+tit-second.AppendBuildInterfaceIncludes();
+  }
 }
 
   // Add generator specific helper commands

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=51bb509b52b51983b5e8c48f08cc23c7faaeb2f5
commit 51bb509b52b51983b5e8c48f08cc23c7faaeb2f5
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 21:50:24 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Feb 7 21:50:24 2013 +0100

INTERFACE_INCLUDE_DIRECTORIES should also be populated for static libs.

diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx
index 93a3ae0..dd138a3 100644
--- a/Source/cmDocumentVariables.cxx
+++ b/Source/cmDocumentVariables.cxx
@@ -1151,9 +1151,9 @@ void cmDocumentVariables::DefineVariables(cmake* cm)
  Automatically add the current source- and build directories 
  to the INTERFACE_INCLUDE_DIRECTORIES.,
  If this variable is enabled, CMake automatically adds for each shared 
- library target, module target and executable target, 
- ${CMAKE_CURRENT_SOURCE_DIR} and ${CMAKE_CURRENT_BINARY_DIR} to the 
- INTERFACE_INCLUDE_DIRECTORIES.
+ library target, static library target, module target and executable 
+ target, ${CMAKE_CURRENT_SOURCE_DIR} and ${CMAKE_CURRENT_BINARY_DIR} to 
+ the INTERFACE_INCLUDE_DIRECTORIES.
  By default CMAKE_BUILD_INTERFACE_INCLUDES is OFF.,
  false,
  Variables that Control the Build);
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 378c7b5..52f6e03 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2715,6 +2715,7 @@ void cmTarget::AppendProperty(const char* prop, const 
char* value,
 void cmTarget::AppendBuildInterfaceIncludes()
 {
   if(this-GetType() != cmTarget::SHARED_LIBRARY 
+ this-GetType() != cmTarget::STATIC_LIBRARY 
  this-GetType() != cmTarget::MODULE_LIBRARY 
  !this-IsExecutableWithExports())
 {

---

Summary of changes:
 Source/cmDocumentVariables.cxx |6 +++---
 Source/cmGlobalGenerator.cxx   |5 +
 Source/cmTarget.cxx|1 +
 3 files changed, 9 insertions(+), 3 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v2.8.10.2-2019-g37bdf11

2013-02-07 Thread Stephen Kelly

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  37bdf11cce238f61210da0cf9e1ccd57a17bef3a (commit)
   via  3c4b16bec19dbacf1cb4d413771901da17eab2e1 (commit)
   via  df74bc34d4219a8d6e63ec7e41a9ca4fbe355581 (commit)
  from  5f456ded1e6426c57f82306f36a517875898a68a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=37bdf11cce238f61210da0cf9e1ccd57a17bef3a
commit 37bdf11cce238f61210da0cf9e1ccd57a17bef3a
Merge: 5f456de 3c4b16b
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 16:10:28 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 7 16:10:28 2013 -0500

Merge topic 'minor-fixes' into next

3c4b16b Ensure that the build interface includes have been added.
df74bc3 Only append build interface include dirs to particular targets.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c4b16bec19dbacf1cb4d413771901da17eab2e1
commit 3c4b16bec19dbacf1cb4d413771901da17eab2e1
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 19:35:00 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Feb 7 22:07:54 2013 +0100

Ensure that the build interface includes have been added.

This is needed in the case that Automoc is used, as that calls
GetIncludeDirectories, which may cache the resulting include dirs
too early in the generate step.

We still need to invoke AppendBuildInterfaceIncludes
in the GlobalGenerator because the build interface includes affect
mostly the dependencies of targets (such as the automoc targets),
rather than the targets themselves, so the build interface needs
to be appended for all targets before generation is done.

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 2945173..52f6e03 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2767,6 +2767,7 @@ std::vectorstd::string 
cmTarget::GetIncludeDirectories(const char *config)
   this-GetName(),
   INCLUDE_DIRECTORIES, 0, 0);
 
+  this-AppendBuildInterfaceIncludes();
 
   std::vectorstd::string debugProperties;
   const char *debugProp =

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=df74bc34d4219a8d6e63ec7e41a9ca4fbe355581
commit df74bc34d4219a8d6e63ec7e41a9ca4fbe355581
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 19:31:23 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Feb 7 21:57:35 2013 +0100

Only append build interface include dirs to particular targets.

We shouldn't set the property on all custom targets.

diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx
index 08b3ef1..dd138a3 100644
--- a/Source/cmDocumentVariables.cxx
+++ b/Source/cmDocumentVariables.cxx
@@ -1150,9 +1150,10 @@ void cmDocumentVariables::DefineVariables(cmake* cm)
 (CMAKE_BUILD_INTERFACE_INCLUDES, cmProperty::VARIABLE,
  Automatically add the current source- and build directories 
  to the INTERFACE_INCLUDE_DIRECTORIES.,
- If this variable is enabled, CMake automatically adds for each 
- target ${CMAKE_CURRENT_SOURCE_DIR} and ${CMAKE_CURRENT_BINARY_DIR} 
- to the INTERFACE_INCLUDE_DIRECTORIES.
+ If this variable is enabled, CMake automatically adds for each shared 
+ library target, static library target, module target and executable 
+ target, ${CMAKE_CURRENT_SOURCE_DIR} and ${CMAKE_CURRENT_BINARY_DIR} to 
+ the INTERFACE_INCLUDE_DIRECTORIES.
  By default CMAKE_BUILD_INTERFACE_INCLUDES is OFF.,
  false,
  Variables that Control the Build);
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index f55999f..2945173 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2714,6 +2714,13 @@ void cmTarget::AppendProperty(const char* prop, const 
char* value,
 //
 void cmTarget::AppendBuildInterfaceIncludes()
 {
+  if(this-GetType() != cmTarget::SHARED_LIBRARY 
+ this-GetType() != cmTarget::STATIC_LIBRARY 
+ this-GetType() != cmTarget::MODULE_LIBRARY 
+ !this-IsExecutableWithExports())
+{
+return;
+}
   if (this-BuildInterfaceIncludesAppended)
 {
 return;

---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v2.8.10.2-2021-g5948a98

2013-02-07 Thread Stephen Kelly

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  5948a987e8633f6be2aa140051a3d8e8954e3bb0 (commit)
   via  c85052786e88b0b82e4c57dff47c5a17bc841dde (commit)
  from  37bdf11cce238f61210da0cf9e1ccd57a17bef3a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5948a987e8633f6be2aa140051a3d8e8954e3bb0
commit 5948a987e8633f6be2aa140051a3d8e8954e3bb0
Merge: 37bdf11 c850527
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 18:07:43 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 7 18:07:43 2013 -0500

Merge topic 'minor-fixes' into next

c850527 There are 10 difficult problems in computer science:


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c85052786e88b0b82e4c57dff47c5a17bc841dde
commit c85052786e88b0b82e4c57dff47c5a17bc841dde
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 23:55:02 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Thu Feb 7 23:55:02 2013 +0100

There are 10 difficult problems in computer science:

 * Naming things
 * Cache invalidation
 * Off-by-one errors

And this feature has them all.

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 52f6e03..59afcb6 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2809,7 +2809,8 @@ std::vectorstd::string 
cmTarget::GetIncludeDirectories(const char *config)
 this,
 dagChecker),
   entryIncludes);
-  if (!(*it)-ge-GetHadContextSensitiveCondition())
+  if (this-Makefile-IsGeneratingBuildSystem()
+   !(*it)-ge-GetHadContextSensitiveCondition())
 {
 cacheIncludes = true;
 }

---

Summary of changes:
 Source/cmTarget.cxx |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v2.8.10.2-2023-g623f04a

2013-02-07 Thread Stephen Kelly

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, next has been updated
   via  623f04a71ceb2687b2b2b7cb961f45a848902a3e (commit)
   via  1f17a9f39f579459c2c0a68001aaa828fdbc0dc0 (commit)
  from  5948a987e8633f6be2aa140051a3d8e8954e3bb0 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=623f04a71ceb2687b2b2b7cb961f45a848902a3e
commit 623f04a71ceb2687b2b2b7cb961f45a848902a3e
Merge: 5948a98 1f17a9f
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 18:10:56 2013 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Feb 7 18:10:56 2013 -0500

Merge topic 'minor-fixes' into next

1f17a9f Ensure that the build interface includes have been added.


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1f17a9f39f579459c2c0a68001aaa828fdbc0dc0
commit 1f17a9f39f579459c2c0a68001aaa828fdbc0dc0
Author: Stephen Kelly steve...@gmail.com
AuthorDate: Thu Feb 7 19:35:00 2013 +0100
Commit: Stephen Kelly steve...@gmail.com
CommitDate: Fri Feb 8 00:08:06 2013 +0100

Ensure that the build interface includes have been added.

This is needed in the case that Automoc is used, as that calls
GetIncludeDirectories, which may cache the resulting include dirs
too early in the generate step.

Also, because the automoc step is so early, we can't cache the
include directories at that point. At that point the build interface
of all dependencies are not populated yet, so we'd be caching the
includes before appending the build interface. Only start caching
when we're definitely generating the buildsystem. At that point, the
includes should be stable.

We still need to invoke AppendBuildInterfaceIncludes
in the GlobalGenerator because the build interface includes affect
mostly the dependencies of targets (such as the automoc targets),
rather than the targets themselves, so the build interface needs
to be appended for all targets before generation is done.

diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 2945173..59afcb6 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -2767,6 +2767,7 @@ std::vectorstd::string 
cmTarget::GetIncludeDirectories(const char *config)
   this-GetName(),
   INCLUDE_DIRECTORIES, 0, 0);
 
+  this-AppendBuildInterfaceIncludes();
 
   std::vectorstd::string debugProperties;
   const char *debugProp =
@@ -2808,7 +2809,8 @@ std::vectorstd::string 
cmTarget::GetIncludeDirectories(const char *config)
 this,
 dagChecker),
   entryIncludes);
-  if (!(*it)-ge-GetHadContextSensitiveCondition())
+  if (this-Makefile-IsGeneratingBuildSystem()
+   !(*it)-ge-GetHadContextSensitiveCondition())
 {
 cacheIncludes = true;
 }

---

Summary of changes:


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v2.8.10.2-611-gbc96f95

2013-02-07 Thread Kitware Robot

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.

The branch, master has been updated
   via  bc96f95a162045751ff52db19b0791e9eb818cd8 (commit)
  from  bc75f4c4c606412429e97d12ef1d550e7096cdfc (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc96f95a162045751ff52db19b0791e9eb818cd8
commit bc96f95a162045751ff52db19b0791e9eb818cd8
Author: Kitware Robot kwro...@kitware.com
AuthorDate: Fri Feb 8 00:01:15 2013 -0500
Commit: Kitware Robot kwro...@kitware.com
CommitDate: Fri Feb 8 00:01:15 2013 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 0be7d05..1b33cde 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -2,5 +2,5 @@
 set(CMake_VERSION_MAJOR 2)
 set(CMake_VERSION_MINOR 8)
 set(CMake_VERSION_PATCH 10)
-set(CMake_VERSION_TWEAK 20130207)
+set(CMake_VERSION_TWEAK 20130208)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits

39 matches

Mail list logo