date:20110802

On Mon, Aug 1, 2011 at 8:34 PM, John R. Cary c...@txcorp.com wrote:
 I believe I have followed what I have found on the web for
 building a Win64 version of CMake.  I have downloaded the
 win32 version and used it to configure the cmake source.
 I used the Visual Studio 9 2008 Win64 generator.

 However, when I then use that cmake to configure vtk (an
 old version, 5.0.0) I get the much discussed error,

 -- Loading VTK CMake commands
 CMake Error at CMake/vtkLoadCMakeExtensions.cmake:7 (LOAD_COMMAND):
  load_command Attempt to load the library
  C:/winsame/cary/builds-vs9/composerall/vtk-5.0.0i/ser/CMake/cmVTK_WRAP_TCL2.dll
  failed.  Additional error info is:

  The application has failed to start because its side-by-side configuration
  is incorrect.  Please see the application event log or use the command-line
  sxstrace.exe tool for more detail.

 Call Stack (most recent call first):
  CMake/vtkLoadCMakeExtensions.cmake:27 (VTK_LOAD_SINGLE_CMAKE_EXTENSION)
  CMakeLists.txt:632 (VTK_LOAD_CMAKE_EXTENSIONS)


 CMake Error at CMake/vtkLoadCMakeExtensions.cmake:11 (MESSAGE):
  Loading VTK command VTK_WRAP_TCL2 - failed
 Call Stack (most recent call first):
  CMake/vtkLoadCMakeExtensions.cmake:27 (VTK_LOAD_SINGLE_CMAKE_EXTENSION)
  CMakeLists.txt:632 (VTK_LOAD_CMAKE_EXTENSIONS)

 Using sxstrace shows

 INFO: Parsing Manifest File
 C:\winsame\cary\builds-vs9\composerall\vtk-5.0.0i\ser\CMake\cmVTK_WRAP_TCL2.dll.
    INFO: Manifest Definition Identity is (null).
    INFO: Reference:
 Microsoft.VC90.DebugCRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8
 INFO: Resolving reference
 Microsoft.VC90.DebugCRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8.
    INFO: Resolving reference for ProcessorArchitecture amd64.

 which seems to indicate that even though I built cmake with the VS9-Win64
 generator, cmake somehow created the dll as win32?  Even though cmake
 says,

 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
 Studio
 9.0/VC/bin/amd64/cl.exe


 showing that it found the 64-bit compiler?

 Any hints on what to do next?

 Thx...John Cary







 ___
 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


This is a problem with VTK 5.0, not a problem with CMake...

Since VTK 5.0, the loaded custom CMake commands have been eliminated
from VTK for just this reason. Can you use VTK 5.2, 5.4 or 6.5
instead...? (I'm not 100% sure exactly when that problem was fixed,
but a more recent VTK should fix this 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://www.cmake.org/mailman/listinfo/cmake

Re: [CMake] How to create a 64-bit Windows build of cmake?

On Tue, Aug 2, 2011 at 7:00 AM, David Cole david.c...@kitware.com wrote:
 On Mon, Aug 1, 2011 at 8:34 PM, John R. Cary c...@txcorp.com wrote:
 I believe I have followed what I have found on the web for
 building a Win64 version of CMake.  I have downloaded the
 win32 version and used it to configure the cmake source.
 I used the Visual Studio 9 2008 Win64 generator.

 However, when I then use that cmake to configure vtk (an
 old version, 5.0.0) I get the much discussed error,

 -- Loading VTK CMake commands
 CMake Error at CMake/vtkLoadCMakeExtensions.cmake:7 (LOAD_COMMAND):
  load_command Attempt to load the library
  C:/winsame/cary/builds-vs9/composerall/vtk-5.0.0i/ser/CMake/cmVTK_WRAP_TCL2.dll
  failed.  Additional error info is:

  The application has failed to start because its side-by-side configuration
  is incorrect.  Please see the application event log or use the command-line
  sxstrace.exe tool for more detail.

 Call Stack (most recent call first):
  CMake/vtkLoadCMakeExtensions.cmake:27 (VTK_LOAD_SINGLE_CMAKE_EXTENSION)
  CMakeLists.txt:632 (VTK_LOAD_CMAKE_EXTENSIONS)


 CMake Error at CMake/vtkLoadCMakeExtensions.cmake:11 (MESSAGE):
  Loading VTK command VTK_WRAP_TCL2 - failed
 Call Stack (most recent call first):
  CMake/vtkLoadCMakeExtensions.cmake:27 (VTK_LOAD_SINGLE_CMAKE_EXTENSION)
  CMakeLists.txt:632 (VTK_LOAD_CMAKE_EXTENSIONS)

 Using sxstrace shows

 INFO: Parsing Manifest File
 C:\winsame\cary\builds-vs9\composerall\vtk-5.0.0i\ser\CMake\cmVTK_WRAP_TCL2.dll.
    INFO: Manifest Definition Identity is (null).
    INFO: Reference:
 Microsoft.VC90.DebugCRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8
 INFO: Resolving reference
 Microsoft.VC90.DebugCRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8.
    INFO: Resolving reference for ProcessorArchitecture amd64.

 which seems to indicate that even though I built cmake with the VS9-Win64
 generator, cmake somehow created the dll as win32?  Even though cmake
 says,

 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
 Studio
 9.0/VC/bin/amd64/cl.exe


 showing that it found the 64-bit compiler?

 Any hints on what to do next?

 Thx...John Cary







 ___
 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


 This is a problem with VTK 5.0, not a problem with CMake...

 Since VTK 5.0, the loaded custom CMake commands have been eliminated
 from VTK for just this reason. Can you use VTK 5.2, 5.4 or 6.5
 instead...? (I'm not 100% sure exactly when that problem was fixed,
 but a more recent VTK should fix this issue.)


make that 5.2, 5.4 or **5.6**...
___
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] VS2010 and superbuild - Fwd: [Ctk-developers] VS2010 support

On Mon, Aug 1, 2011 at 5:59 PM, Sascha Zelzer
s.zel...@dkfz-heidelberg.de wrote:
Hi,

I played around with the ExternalProject unit tests and was able to
reproduce my problem with the current HEAD ExternalProjects.cmake file. It
boils down to *not* adding the UPDATE_COMMAND line:

1.) In CMake/Tests/ExternalProject/CMakeLists.txt:487 remove (or comment in)
the UPDATE_COMMAND argument
2.) Build the TutorialStep1-GIT-bytag project with VisualStudio 2010 (I am
using the Express Edition). You will get:

1-- Rebuild All started: Project: TutorialStep1-GIT-bytag,
Configuration: Debug Win32 --
1 Creating directories for 'TutorialStep1-GIT-bytag'
1 Building Custom Rule
C:/Development/git/CMake/Tests/ExternalProject/CMakeLists.txt
1 CMake does not need to re-run because
C:\Development\build\ExternalProject-Test\CMakeFiles\generate.stamp is
up-to-date.
1 Performing download step (git clone) for 'TutorialStep1-GIT-bytag'
1 Cloning into TutorialStep1-GIT-bytag...
1 done.
1 Note: checking out 'origin/master'.
1
1 You are in 'detached HEAD' state. You can look around, make experimental
1 changes and commit them, and you can discard any commits you make in
this
1 state without impacting any branches by performing another checkout.
1
1 If you want to create a new branch to retain commits you create, you may
1 do so (now or later) by using -b with the checkout command again.
Example:
1
1 git checkout -b new_branch_name
1
1 HEAD is now at d197073... Initial import into repo.
1 Performing update step (git fetch) for 'TutorialStep1-GIT-bytag'
== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==

So all other steps after the update step are ignored.

In CTK, we rely on the default update command for git and it works in Visual
Studio 2008. Any ideas how to fix this will be greatly appreciated.

Thanks,
Sascha

On 07/29/2011 12:40 PM, David Cole wrote:

Can you send along the output that you do see when your project is
downloading, and the build output that immediately follows that? Does it say
anything about the steps that come after download?

For example, when I build the ExternalProject test and build only the
project TutorialStep5-Local, I get the following output:

1 Performing download step (DIR copy) for 'TutorialStep5-Local'
1 No update step for 'TutorialStep5-Local'
1 No patch step for 'TutorialStep5-Local'
1 Performing configure step for 'TutorialStep5-Local'
1 loading initial cache file C:/Users/davidcole/Dashboards/My
Tests/b20/CMakeExternals/tmp/TutorialStep5-Local/TutorialStep5-Local-cache.cmake
1 -- Check for working C compiler using: Visual Studio 10
1 -- Check for working C compiler using: Visual Studio 10 -- works
1 -- Detecting C compiler ABI info
1 -- Detecting C compiler ABI info - done
1 -- Check for working CXX compiler using: Visual Studio 10
1 -- Check for working CXX compiler using: Visual Studio 10 -- works
1 -- Detecting CXX compiler ABI info
1 -- Detecting CXX compiler ABI info - done
1 -- Looking for log
1 -- Looking for log - found
1 -- Looking for exp
1 -- Looking for exp - found
1 -- Configuring done
1 -- Generating done
1 -- Build files have been written to: C:/Users/davidcole/Dashboards/My
Tests/b20/CMakeExternals/Build/TutorialStep5-Local
1 Performing build step for 'TutorialStep5-Local'
.

Do you see any Performing XXX step or No XXX step output after the
download occurs...?

On Fri, Jul 29, 2011 at 6:30 AM, David Cole david.c...@kitware.com wrote:

Is your VS 2010 in German by any chance? (Or the path name to the
installation of VS 2010?)

We do not typically test on non-English platforms or build tools...

On Fri, Jul 29, 2011 at 2:14 AM, Sascha Zelzer
s.zel...@dkfz-heidelberg.de wrote:

Hi,

Thanks David and Yuri for the information. In my case (with CTK), there
are no error messages. The download step is successfully completed and the
following steps are just skipped. VS then reports that everything was
successfull (or up-to-date).

I will play with your test cases and my VS 2010 installation.

Thanks,
Sascha

On 07/29/2011 12:30 AM, David Cole wrote:

The ExternalProject test in the CMake test suite passes on Visual Studio
2010.

You can see all the variations of ExternalProject usage the test tries
in this file:

http://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/ExternalProject/CMakeLists.txt;h=4a542d722ff127e672a63082c6bb35de1f3ef9cd;hb=b6fb213ed1431321fab0705beb3aae82f451dcc8

Are there any error messages you get? Or are steps just skipped?

??
David

On Wed, Jul 27, 2011 at 11:38 PM, Yuri Timenkovy...@timenkov.ru
wrote:

I'm not sure I understood your question, but now I use ExternalProject
(from
CMake 2.8.4) with Visual Studio 2010 which has 2 externals: one built
with
custom command (the C# project) and the second one is CMake-based but
with
VC6 generator. Everything compiles and works fine. But I

Re: [CMake] How to create a 64-bit Windows build of cmake?

2011-08-02 Thread John R. Cary

Thanks for your response. This will definitely decrease my headpain.

It turns out that I need vtk-5.0.0, but right now I am not sure
that I need the wrapping code. Am checking on this.

Would it make sense to just not call vtkLoadCMakeExtensions.cmake?

ThxJohn Cary

On 8/2/11 5:00 AM, David Cole wrote:

On Tue, Aug 2, 2011 at 7:00 AM, David Coledavid.c...@kitware.com wrote:

On Mon, Aug 1, 2011 at 8:34 PM, John R. Caryc...@txcorp.com wrote:

I believe I have followed what I have found on the web for
building a Win64 version of CMake. I have downloaded the
win32 version and used it to configure the cmake source.
I used the Visual Studio 9 2008 Win64 generator.

However, when I then use that cmake to configure vtk (an
old version, 5.0.0) I get the much discussed error,

-- Loading VTK CMake commands
CMake Error at CMake/vtkLoadCMakeExtensions.cmake:7 (LOAD_COMMAND):
load_command Attempt to load the library

C:/winsame/cary/builds-vs9/composerall/vtk-5.0.0i/ser/CMake/cmVTK_WRAP_TCL2.dll
failed. Additional error info is:

The application has failed to start because its side-by-side configuration
is incorrect. Please see the application event log or use the command-line
sxstrace.exe tool for more detail.

Call Stack (most recent call first):
CMake/vtkLoadCMakeExtensions.cmake:27 (VTK_LOAD_SINGLE_CMAKE_EXTENSION)
CMakeLists.txt:632 (VTK_LOAD_CMAKE_EXTENSIONS)

CMake Error at CMake/vtkLoadCMakeExtensions.cmake:11 (MESSAGE):
Loading VTK command VTK_WRAP_TCL2 - failed
Call Stack (most recent call first):
CMake/vtkLoadCMakeExtensions.cmake:27 (VTK_LOAD_SINGLE_CMAKE_EXTENSION)
CMakeLists.txt:632 (VTK_LOAD_CMAKE_EXTENSIONS)

Using sxstrace shows

INFO: Parsing Manifest File
C:\winsame\cary\builds-vs9\composerall\vtk-5.0.0i\ser\CMake\cmVTK_WRAP_TCL2.dll.
INFO: Manifest Definition Identity is (null).
INFO: Reference:
Microsoft.VC90.DebugCRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8
INFO: Resolving reference
Microsoft.VC90.DebugCRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8.
INFO: Resolving reference for ProcessorArchitecture amd64.

which seems to indicate that even though I built cmake with the VS9-Win64
generator, cmake somehow created the dll as win32? Even though cmake
says,

-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio
9.0/VC/bin/amd64/cl.exe

showing that it found the 64-bit compiler?

Any hints on what to do next?

Thx...John Cary

___
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

This is a problem with VTK 5.0, not a problem with CMake...

Since VTK 5.0, the loaded custom CMake commands have been eliminated
from VTK for just this reason. Can you use VTK 5.2, 5.4 or 6.5
instead...? (I'm not 100% sure exactly when that problem was fixed,
but a more recent VTK should fix this issue.)

make that 5.2, 5.4 or **5.6**...

___
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] How to create a 64-bit Windows build of cmake?

Try commenting out the one line that causes problems, then back up
from there, either commenting chunks out or adjusting CMake options
until those commands are not loaded.

On Tue, Aug 2, 2011 at 8:50 AM, John R. Cary c...@txcorp.com wrote:
Thanks for your response. This will definitely decrease my headpain.

It turns out that I need vtk-5.0.0, but right now I am not sure
that I need the wrapping code. Am checking on this.

Would it make sense to just not call vtkLoadCMakeExtensions.cmake?

ThxJohn Cary

On 8/2/11 5:00 AM, David Cole wrote:

On Tue, Aug 2, 2011 at 7:00 AM, David Coledavid.c...@kitware.com wrote:

On Mon, Aug 1, 2011 at 8:34 PM, John R. Caryc...@txcorp.com wrote:

However, when I then use that cmake to configure vtk (an
old version, 5.0.0) I get the much discussed error,

-- Loading VTK CMake commands
CMake Error at CMake/vtkLoadCMakeExtensions.cmake:7 (LOAD_COMMAND):
load_command Attempt to load the library

C:/winsame/cary/builds-vs9/composerall/vtk-5.0.0i/ser/CMake/cmVTK_WRAP_TCL2.dll
failed. Additional error info is:

The application has failed to start because its side-by-side
configuration
is incorrect. Please see the application event log or use the
command-line
sxstrace.exe tool for more detail.

Call Stack (most recent call first):
CMake/vtkLoadCMakeExtensions.cmake:27 (VTK_LOAD_SINGLE_CMAKE_EXTENSION)
CMakeLists.txt:632 (VTK_LOAD_CMAKE_EXTENSIONS)

Using sxstrace shows

INFO: Parsing Manifest File

C:\winsame\cary\builds-vs9\composerall\vtk-5.0.0i\ser\CMake\cmVTK_WRAP_TCL2.dll.
INFO: Manifest Definition Identity is (null).
INFO: Reference:

Microsoft.VC90.DebugCRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8
INFO: Resolving reference

Microsoft.VC90.DebugCRT,processorArchitecture=amd64,publicKeyToken=1fc8b3b9a1e18e3b,type=win32,version=9.0.21022.8.
INFO: Resolving reference for ProcessorArchitecture amd64.

which seems to indicate that even though I built cmake with the
VS9-Win64
generator, cmake somehow created the dll as win32? Even though cmake
says,

-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio
9.0/VC/bin/amd64/cl.exe

showing that it found the 64-bit compiler?

Any hints on what to do next?

Thx...John Cary

___
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

This is a problem with VTK 5.0, not a problem with CMake...

make that 5.2, 5.4 or **5.6**...

___
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] How to create a 64-bit Windows build of cmake?

2011-08-02 Thread Bill Hoffman


On 8/2/2011 9:42 AM, David Cole wrote:

Try commenting out the one line that causes problems, then back up
from there, either commenting chunks out or adjusting CMake options
until those commands are not loaded.

That said, if CMake is built with the same options as you are building 
VTK with, then it should work.  The trick is to make sure the compiler 
options are exactly the same (Debug to Debug, Release to Release, 64 bit 
to 64 bit).  CMake will be compiling the plugin using the c++/c flags 
for VTK.  Then loading that plugin into CMake.



-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] Regenerating project files based on external file.

2011-08-02 Thread Michael Hertling

On 08/01/2011 07:13 PM, The Novice Coder wrote:
 
 The short version of what I'm trying to do:
 Add some kind of definition to the cmake file that specifies a file, 
 that if modified, will cause the project to be regenerated.
 
 
 Longer (more specific) version.
 We (our small program team) want's to use cmake to generate a file 
 svn_version.h, which has a solution posted on the web.  The problem 
 happens when we checkout new revisions, this file goes unmodified.  
 Looking for a way to cause CMake to regenerate the build files (and with 
 it, the revision number) after an svn up command, without having to 
 touch cmakelists.txt.  It would be trivial to simply check files in the 
 .svn folder for modification times, so that would probably be the 
 easiest (although not 100% accurate) way to go.
 
 Any help on where to look... Thanks!

The usual solution is a custom target which (re)generates svn_version.h
if necessary, i.e. if it would change, to mark it as GENERATED and have
the other targets depend on that custom one. In this way, svn_version.h
is always up-to-date, doesn't trigger unnecessary rebuilds and can be
used normally without invalidating the build files and rebuilding the
whole project subsequently. E.g., you might use a CMake script calling
CONFIGURE_FILE() to regenerate svn_version.h from a template to ensure
it doesn't get touched if nothing has changed:

ADD_CUSTOM_TARGET(svn_version
${CMAKE_COMMAND} -P ${CMAKE_SOURCE_DIR}/svn_version.cmake
)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_BINARY_DIR}/svn_version.h
PROPERTIES GENERATED TRUE
)
FOREACH(i target_1 target_2 ... target_n)
ADD_DEPENDENCIES(${i} svn_version)
ENDFOREACH()

# svn_version.cmake:
# set up variables
CONFIGURE_FILE(path/to/svn_version.h.in path/to/svn_version.h)

Do you have special requirements because of which you definitely
need the build files regenerated, i.e. the project reconfigured
and rebuilt instead of just updating svn_version.h?

Regards,

Michael
___
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] VS2010 and superbuild - Fwd: [Ctk-developers] VS2010 support

2011-08-02 Thread Jean-Christophe Fillion-Robin

Within CTK,

Where we are specifying a specific SHA1, we could set UPDATE_COMMAND to be


Where we are specifying a branch like origin/master, this is were the
problem occurs. I guess we could also specify a given SHA1. This will
prevent the external project to be a moving target and will ensure all
developers will build using the same version of external projects.

What about specifying an SHA1 for external project like VTK, ITK, ...

Thanks
Jc

On Tue, Aug 2, 2011 at 7:28 AM, David Cole david.c...@kitware.com wrote:

 On Mon, Aug 1, 2011 at 5:59 PM, Sascha Zelzer
 s.zel...@dkfz-heidelberg.de wrote:
  Hi,
 
  I played around with the ExternalProject unit tests and was able to
  reproduce my problem with the current HEAD ExternalProjects.cmake file.
 It
  boils down to *not* adding the UPDATE_COMMAND  line:
 
  1.) In CMake/Tests/ExternalProject/CMakeLists.txt:487 remove (or comment
 in)
  the UPDATE_COMMAND argument
  2.) Build the TutorialStep1-GIT-bytag project with VisualStudio 2010 (I
 am
  using the Express Edition). You will get:
 
  1-- Rebuild All started: Project: TutorialStep1-GIT-bytag,
  Configuration: Debug Win32 --
  1  Creating directories for 'TutorialStep1-GIT-bytag'
  1  Building Custom Rule
  C:/Development/git/CMake/Tests/ExternalProject/CMakeLists.txt
  1  CMake does not need to re-run because
  C:\Development\build\ExternalProject-Test\CMakeFiles\generate.stamp is
  up-to-date.
  1  Performing download step (git clone) for 'TutorialStep1-GIT-bytag'
  1  Cloning into TutorialStep1-GIT-bytag...
  1  done.
  1  Note: checking out 'origin/master'.
  1
  1  You are in 'detached HEAD' state. You can look around, make
 experimental
  1  changes and commit them, and you can discard any commits you make in
  this
  1  state without impacting any branches by performing another checkout.
  1
  1  If you want to create a new branch to retain commits you create, you
 may
  1  do so (now or later) by using -b with the checkout command again.
  Example:
  1
  1git checkout -b new_branch_name
  1
  1  HEAD is now at d197073... Initial import into repo.
  1  Performing update step (git fetch) for 'TutorialStep1-GIT-bytag'
  == Rebuild All: 1 succeeded, 0 failed, 0 skipped ==
 
  So all other steps after the update step are ignored.
 
  In CTK, we rely on the default update command for git and it works in
 Visual
  Studio 2008. Any ideas how to fix this will be greatly appreciated.
 
  Thanks,
  Sascha
 
 
 
  On 07/29/2011 12:40 PM, David Cole wrote:
 
  Can you send along the output that you do see when your project is
  downloading, and the build output that immediately follows that? Does it
 say
  anything about the steps that come after download?
 
  For example, when I build the ExternalProject test and build only the
  project TutorialStep5-Local, I get the following output:
 
  1  Performing download step (DIR copy) for 'TutorialStep5-Local'
  1  No update step for 'TutorialStep5-Local'
  1  No patch step for 'TutorialStep5-Local'
  1  Performing configure step for 'TutorialStep5-Local'
  1  loading initial cache file C:/Users/davidcole/Dashboards/My
 
 Tests/b20/CMakeExternals/tmp/TutorialStep5-Local/TutorialStep5-Local-cache.cmake
  1  -- Check for working C compiler using: Visual Studio 10
  1  -- Check for working C compiler using: Visual Studio 10 -- works
  1  -- Detecting C compiler ABI info
  1  -- Detecting C compiler ABI info - done
  1  -- Check for working CXX compiler using: Visual Studio 10
  1  -- Check for working CXX compiler using: Visual Studio 10 -- works
  1  -- Detecting CXX compiler ABI info
  1  -- Detecting CXX compiler ABI info - done
  1  -- Looking for log
  1  -- Looking for log - found
  1  -- Looking for exp
  1  -- Looking for exp - found
  1  -- Configuring done
  1  -- Generating done
  1  -- Build files have been written to: C:/Users/davidcole/Dashboards/My
  Tests/b20/CMakeExternals/Build/TutorialStep5-Local
  1  Performing build step for 'TutorialStep5-Local'
  .
 
 
  Do you see any Performing XXX step or No XXX step output after the
  download occurs...?
 
 
 
  On Fri, Jul 29, 2011 at 6:30 AM, David Cole david.c...@kitware.com
 wrote:
 
  Is your VS 2010 in German by any chance? (Or the path name to the
  installation of VS 2010?)
 
  We do not typically test on non-English platforms or build tools...
 
 
  On Fri, Jul 29, 2011 at 2:14 AM, Sascha Zelzer
  s.zel...@dkfz-heidelberg.de wrote:
 
  Hi,
 
  Thanks David and Yuri for the information. In my case (with CTK), there
  are no error messages. The download step is successfully completed and
 the
  following steps are just skipped. VS then reports that everything was
  successfull (or up-to-date).
 
  I will play with your test cases and my VS 2010 installation.
 
  Thanks,
  Sascha
 
  On 07/29/2011 12:30 AM, David Cole wrote:
 
  The ExternalProject test in the CMake test suite passes on Visual
 Studio
  2010.
 
  You can see all the variations of ExternalProject

[CMake] Assembly language support using gcc or gas

2011-08-02 Thread Glenn Coombs

Previously with cmake 2.8.4 we were using these lines to compile an assembly
language file in our project:

if(UNIX)
enable_language(ASM)

# see if we are building 32-bit or 64-bit executables
file(WRITE ${CMAKE_BINARY_DIR}/check_32or64bit.cpp int main(int argc,
char *argv[]) { return 8 * sizeof(char *); }\n)

try_run(
run_result
compile_result
${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}/check_32or64bit.cpp
)

if (${run_result} EQUAL 32)
list(APPEND sources src/sysc/qt/md/i386.s)
if(APPLE)
set(ASM_SYS_FLAGS -arch i386)
else()
set(ASM_SYS_FLAGS -32)
endif()
else()
list(APPEND sources src/sysc/qt/md/iX86_64.s)
if(APPLE)
set(ASM_SYS_FLAGS -arch x86_64)
else()
set(ASM_SYS_FLAGS -64)
endif()
endif()

set(CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT
CMAKE_ASM${ASM_DIALECT}_COMPILER ${ASM_SYS_FLAGS} -o OBJECT SOURCE)
endif()

And this resulted in the appropriate 32-bit or 64-bit assembler file being
compiled like so:

/usr/bin/as  -32 -o path snipped/i386.s.o  path-snipped/i386.s
/usr/bin/as  -64 -o path snipped/iX86_64.s.o path-snipped/iX86_64.s

Now with cmake 2.8.5 it fails when compiling that assembler file as it uses
/usr/bin/gcc rather than /usr/bin/as and gcc wants -m32 and -c instead of
-32.  When I tried commenting out the line that overrides the default
setting of CMAKE_ASM${ASM_DIALECT}_COMPILE_OBJECT it fails differently:

/usr/bin/gcc  -DEXTERNAL_BUS_WIDTH=128 -DLINUX -DHIDEBUG -O3 -DNDEBUG
-I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src
-I/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/kernel
-DNOMINMAX -DUSE_SIM_NAMESPACE -o
CMakeFiles/systemc.dir/src/sysc/qt/md/i386.s.o -c
/user/grc/msvdx-cvsfiles/sim/msvdx-cmake-2.8.5/systemC/src/sysc/qt/md/i386.s

i386.s:69: Error: suffix or operands invalid for `push'

This line works if I add the -m32 option using set(CMAKE_ASM_FLAGS -m32)
but should all the preprocessor defines (-DXXX) and include directory
arguments (-IXXX) be present ?  I was thinking they were only for C/C++
files, no ?

And what is the recommended way to compile an assembly language file that
will work on both 2.8.4 and 2.8.5 ?

--
Glenn
___
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] Gathering up required shared libraries

On Monday, August 01, 2011 07:12:15 pm Gregory Crosswhite wrote:
 Hey everyone,
 
 I am using CMake to build a package which has the normal unix layout,
 i.e. programs are in bin/, libraries are in lib/, etc., and I would like
 to simply copy all of the required shared non-system libraries into lib/
 and make sure that the executable is updated to look for them there so
 that I can have an standalone distribution.  CMake *almost* supports
 this with fixup_bundle, but unless I am missing something it doesn't
 seem to give me any control as to where the shared libraries are
 installed, and it doesn't update the executable except on OSX --- though
 the latter is not a big deal since if I understand correctly I can just
 add @executable_path@/../lib to the RPATH.  Furthermore, on Linux it
 incorrectly assumes that libraries in /usr/lib should be considered
 system libraries (that is, guaranteed to be available everywhere), when
 in fact only libraries in /lib should be, which means that I can't even
 easily use get_prerequisites directly to find all of the libraries that
 I need and then copy them to the correct location myself.
 
 (Of course, an alternative would be to just statically-link everything,
 but frankly having searched around it looks like it is simply impossible
 for me to force all non-system libraries to be statically linked,
 especially since once of them is libgfortran which is included
 automatically by the gfortran compiler and I can't figure out a good way
 to get CMake to reliably link statically to libgfortran instead of
 dynamically.  If anyone has any recommendations on this front I would be
 happy to hear them.)
 
 So anyway, at the moment to do what I want it looks like I would have to
 make my own project-specific copies of GetPrerequisites.cmake and
 BundleUtilities.cmake and then hack them up in order to force them to do
 what I want.  But I can't help but think that there must have lots of
 people out there who have wanted to do what I want to do and so this
 problem must have been solved in a much better way.  So does anyone have
 advice for a way to do what I want, i.e. an easy way to copy all
 non-system libraries (where only /lib is interpreted to be the location
 of system libraries) to a directory of my choosing relative to the
 installation prefix and to modify the executable to make sure it finds
 them?  Or is my only option really to copy into my project and hack up
 GetPrerequisites.cmake and BundleUtilities.cmake?
 

You shouldn't need to copy GetPrerequisites and BundleUtilities.

For Linux you can do:
set_target_properties( ... PROPERTIES INSTALL_RPATH \$ORIGIN/../lib)

To get /usr/lib/ to be treated as non-system libraries, you can implement 
gp_resolved_file_type_override() 
to adjust that behavior.
See gp_item_default_embedded_path() in GetPrerequisites for more information.

And finally, to copy the dependents into lib/ instead of bin/, you can 
implement 
gp_item_default_embedded_path_override() 
to return a different path.
See gp_resolved_file_type() in GetPrerequisites for more information.

-- 
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

Re: [CMake] Gathering up required shared libraries


On 8/2/11 9:28 AM, Clinton Stimpson wrote:

You shouldn't need to copy GetPrerequisites and BundleUtilities.

For Linux you can do:
set_target_properties( ... PROPERTIES INSTALL_RPATH \$ORIGIN/../lib)

To get/usr/lib/  to be treated as non-system libraries, you can implement
gp_resolved_file_type_override()
to adjust that behavior.
See gp_item_default_embedded_path() in GetPrerequisites for more information.

And finally, to copy the dependents into lib/ instead of bin/, you can
implement
gp_item_default_embedded_path_override()
to return a different path.
See gp_resolved_file_type() in GetPrerequisites for more information.


Great!  I knew that there had to be a better way that I was simply 
missing.  Thanks a lot!  :-D


Cheers,
Greg
___
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] Gathering up required shared libraries


On 8/2/11 9:28 AM, Clinton Stimpson wrote:

You shouldn't need to copy GetPrerequisites and BundleUtilities.

For Linux you can do:
set_target_properties( ... PROPERTIES INSTALL_RPATH \$ORIGIN/../lib)

To get /usr/lib/ to be treated as non-system libraries, you can implement
gp_resolved_file_type_override()
to adjust that behavior.
See gp_item_default_embedded_path() in GetPrerequisites for more information.

And finally, to copy the dependents into lib/ instead of bin/, you can
implement
gp_item_default_embedded_path_override()
to return a different path.
See gp_resolved_file_type() in GetPrerequisites for more information.



Okay, so that gets me *nearly* everything that I want, but my new 
problem is that on Mac OSX fixup_bundle incorrectly assumes that the 
bundle directory is where the executable is --- namely, bin/, rather 
than the installation directory --- and then complains that the 
libraries have not been copied into the bundle; if I instead pass in the 
installation directory then it complains because it isn't a .app dir.  
Thanks to your advice I now know to specifically look for *_override 
hooks in the BundleUtilities, but unfortunately unless I am missing 
something it looks like there are no such hooks that will let me change 
this behavior, so I will need to copy BundleUtilities and then modify 
get_dotapp_dir to return the parent of the directory of the executable 
rather than the directory of the executable itself.


Could I request that overrides be added to in BundleUtilities similar to 
the ones in GetPrerequisites so that someone facing my situation won't 
have to do this in the future?  It looks to me though like an override 
in get_dotapp_dir might suffice, and I could easily implement that 
myself by following the pattern for overrides in GetPrerequisites and 
then send you all a patch, but you all have a better sense of the big 
picture than a relative newcomer to hacking on CMake like myself so I 
would be happy for any feedback you have on this idea.  :-)


Cheers,
Greg
___
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] Gathering up required shared libraries

On Tue, Aug 2, 2011 at 3:42 PM, Gregory Crosswhite
gcrosswh...@gmail.com wrote:
 On 8/2/11 9:28 AM, Clinton Stimpson wrote:

 You shouldn't need to copy GetPrerequisites and BundleUtilities.

 For Linux you can do:
 set_target_properties( ... PROPERTIES INSTALL_RPATH \$ORIGIN/../lib)

 To get /usr/lib/ to be treated as non-system libraries, you can implement
 gp_resolved_file_type_override()
 to adjust that behavior.
 See gp_item_default_embedded_path() in GetPrerequisites for more
 information.

 And finally, to copy the dependents into lib/ instead of bin/, you can
 implement
 gp_item_default_embedded_path_override()
 to return a different path.
 See gp_resolved_file_type() in GetPrerequisites for more information.


 Okay, so that gets me *nearly* everything that I want, but my new problem is
 that on Mac OSX fixup_bundle incorrectly assumes that the bundle directory
 is where the executable is --- namely, bin/, rather than the installation
 directory --- and then complains that the libraries have not been copied
 into the bundle; if I instead pass in the installation directory then it
 complains because it isn't a .app dir.  Thanks to your advice I now know
 to specifically look for *_override hooks in the BundleUtilities, but
 unfortunately unless I am missing something it looks like there are no such
 hooks that will let me change this behavior, so I will need to copy
 BundleUtilities and then modify get_dotapp_dir to return the parent of the
 directory of the executable rather than the directory of the executable
 itself.

 Could I request that overrides be added to in BundleUtilities similar to the
 ones in GetPrerequisites so that someone facing my situation won't have to
 do this in the future?  It looks to me though like an override in
 get_dotapp_dir might suffice, and I could easily implement that myself by
 following the pattern for overrides in GetPrerequisites and then send you
 all a patch, but you all have a better sense of the big picture than a
 relative newcomer to hacking on CMake like myself so I would be happy for
 any feedback you have on this idea.  :-)

 Cheers,
 Greg
 ___
 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



The non .app dir problem should go away if you use the recently
released CMake 2.8.5. This bug was fixed in that version:
http://public.kitware.com/Bug/view.php?id=12034
___
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] Gathering up required shared libraries

On Tuesday, August 02, 2011 01:42:47 pm Gregory Crosswhite wrote:
 On 8/2/11 9:28 AM, Clinton Stimpson wrote:
  You shouldn't need to copy GetPrerequisites and BundleUtilities.
  
  For Linux you can do:
  set_target_properties( ... PROPERTIES INSTALL_RPATH \$ORIGIN/../lib)
  
  To get /usr/lib/ to be treated as non-system libraries, you can implement
  gp_resolved_file_type_override()
  to adjust that behavior.
  See gp_item_default_embedded_path() in GetPrerequisites for more
  information.
  
  And finally, to copy the dependents into lib/ instead of bin/, you can
  implement
  gp_item_default_embedded_path_override()
  to return a different path.
  See gp_resolved_file_type() in GetPrerequisites for more information.
 
 Okay, so that gets me *nearly* everything that I want, but my new
 problem is that on Mac OSX fixup_bundle incorrectly assumes that the
 bundle directory is where the executable is --- namely, bin/, rather
 than the installation directory --- and then complains that the
 libraries have not been copied into the bundle; if I instead pass in the
 installation directory then it complains because it isn't a .app dir.
 Thanks to your advice I now know to specifically look for *_override
 hooks in the BundleUtilities, but unfortunately unless I am missing
 something it looks like there are no such hooks that will let me change
 this behavior, so I will need to copy BundleUtilities and then modify
 get_dotapp_dir to return the parent of the directory of the executable
 rather than the directory of the executable itself.
 
 Could I request that overrides be added to in BundleUtilities similar to
 the ones in GetPrerequisites so that someone facing my situation won't
 have to do this in the future?  It looks to me though like an override
 in get_dotapp_dir might suffice, and I could easily implement that
 myself by following the pattern for overrides in GetPrerequisites and
 then send you all a patch, but you all have a better sense of the big
 picture than a relative newcomer to hacking on CMake like myself so I
 would be happy for any feedback you have on this idea.  :-)
 

On Mac, are you making a .app bundle, or are you doing a layout similar to 
Linux, with bin/, lib/ layout, or something else?

What version of CMake are you using?  There was a bug fix in 2.8.5 if not doing 
a .app bundle on Mac.

-- 
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

Re: [CMake] Gathering up required shared libraries


On 8/2/11 12:47 PM, David Cole wrote:

The non .app dir problem should go away if you use the recently
released CMake 2.8.5. This bug was fixed in that version:
http://public.kitware.com/Bug/view.php?id=12034


Thank you very much for the heads up, but I have already been running 
CMake 2.8.5 already and that particular fix doesn't solve my problem 
because I was hoping to put the executables and libraries in different 
directories --- namely bin/ for the executables and lib/ for the 
libraries, to fit the standard unix-style layout --- and the particular 
fix that you linked only helps in the case where all the executables and 
binaries are put in the same directory.


Cheers,
Greg
___
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] Gathering up required shared libraries


On 8/2/11 12:53 PM, Clinton Stimpson wrote:

On Mac, are you making a .app bundle, or are you doing a layout similar to
Linux, with bin/, lib/ layout, or something else?


The latter --- I was hoping to use a layout similar to Linux with bin/, 
lib/, etc. since the program is console-based and so it doesn't have a GUI.


Cheers,
Greg
___
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] Gathering up required shared libraries

On Tuesday, August 02, 2011 02:03:23 pm Gregory Crosswhite wrote:
 On 8/2/11 12:53 PM, Clinton Stimpson wrote:
  On Mac, are you making a .app bundle, or are you doing a layout similar
  to Linux, with bin/, lib/ layout, or something else?
 
 The latter --- I was hoping to use a layout similar to Linux with bin/,
 lib/, etc. since the program is console-based and so it doesn't have a GUI.

Ok, can you make an example that demonstrates the problem?

I think this should work without overriding get_dotapp_dir() in 
BundleUtilities.

-- 
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

Re: [CMake] Assembly language support using gcc or gas

2011-08-02 Thread Alexander Neundorf

Hi,

On Tuesday 02 August 2011, Glenn Coombs wrote:
 Previously with cmake 2.8.4 we were using these lines to compile an

with 2.8.5 there was a major rework of the assembler support (and now it 
finally does not say Assembler support is experimental anymore).
Sorry that this causes inconvenience for you.

If you enable ASM, you get support for assembler via your C/C++ compiler.
That's why you get gcc now instead of as.
If the C/C++ compiler does not support processing assembler files, this 
language can't be enabled.

If you need a real assembler, you have to enable the respective assembler 
dialect. E.g. to get as/gas, you need to enable ASM-ATT.
This should work with both versions.

Let me know if this doesn't work for you.

Alex
___
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] VS2010 and superbuild - Fwd: [Ctk-developers] VS2010 support

2011-08-02 Thread Sascha Zelzer


On 08/02/2011 01:28 PM, David Cole wrote:


Thanks for this info... I've reproduced the problem now, too. I'm not
sure what to do about it yet, but I can make it happen: that's the
first step toward a fix.

There should not be a need for an update step if you're snapped to
particular hash or non-tracking branch/tag, though, should there? So,
this seems like a contrived case to me.
Yes, I agree. As JC mentioned, we frequently use GIT_TAG origin/master 
or similar, which leads to the problems. In most cases, the problems can 
probably be circumvented.

In the real project where this is happening, what git branch are you
tracking that makes this a real problem...?

For CTK, we cmakeified a couple of projects, optionally patched them 
and put the source code in a git repository under the github/commontk 
organization. We then build these projects via ExternalProject_Add(... 
GIT_TAG origin/patched ...) for example. So we already control which 
commits are being used by controlling the patched branch. If we now 
modify this branch, the already cloned repositories would be updated. I 
feel that this is slightly more convenient than additionally (to 
modifying the external project's repository) changing the SHA1 value in 
the appropriate CMake script. But this is maybe personal taste.


Within MITK for example, we have two separate Git repositories. One 
contains the open-source code and the second our internal research code. 
We track the open-source repository via GIT_TAG origin/master and 
people align their internal code by just building the super-project 
(this is one possible workflow).


Thanks,

Sascha
___
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] VS2010 and superbuild - Fwd: [Ctk-developers] VS2010 support

2011-08-02 Thread Sascha Zelzer


Hi,

I agree with JC and will move the CTK discussion to the ctk-developers list.

Thanks,
Sascha

On 08/02/2011 05:21 PM, Jean-Christophe Fillion-Robin wrote:

Within CTK,

Where we are specifying a specific SHA1, we could set UPDATE_COMMAND 
to be 


Where we are specifying a branch like origin/master, this is were 
the problem occurs. I guess we could also specify a given SHA1. This 
will prevent the external project to be a moving target and will 
ensure all developers will build using the same version of external 
projects.


What about specifying an SHA1 for external project like VTK, ITK, ...

Thanks
Jc



___
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] How to installing cmake Config.cmake files under Debian multiarch ?

2011-08-02 Thread Hendrik Sattler

Am Dienstag, 2. August 2011, 21:55:16 schrieb Alexander Neundorf:
 Hi,
 
 until recently, I recommended to install Config.cmake files more or less
 like this:
 
 install(FILES FooConfig.cmake DESTINATION lib${LIB_SUFFIX}/cmake/Foo )
 
 with LIB_SUFFIX being 64 on systems where this is required.
 
 How do I do this on a Debian multiarch system ?
 How do I know in which directory I should install ?

If you use cmake 2.8.5, you can use GNUInstalldirs.cmake and let the user 
specify the multiarch directory to install in (or solve it once in that cmake 
module).
At least that was I am going to do for openobex.

HS
___
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] Gathering up required shared libraries

On Tuesday, August 02, 2011 05:09:04 pm Gregory Crosswhite wrote:
 On 08/02/2011 03:10 PM, Clinton Stimpson wrote:
  On Tuesday, August 02, 2011 03:38:01 pm Gregory Crosswhite wrote:
  You need an @ONLY for configure_file() so it doesn't substitute the ${}
  parts also.
 
 Doh!  Thanks for the tip.  :-)
 
  You should either pass in the executable or a .app/ directory to
  fixup_bundle()
 
 Okay, but what if I have my own shared libraries that I also want to
 fixup that get installed in lib/? 

They will get fixed up if they are either referenced by an executable in the 
bin directory, or if its passed in the second argument of fixup_bundle().

 It would be preferable if
 fixup_bundle were to scan not only everything in bin/ but also
 everything in lib/, since it searches recursively for both executables
 and libraries in the bundle directory, and that is set to bin/ ---
 though I suppose I could work around this manually by passing in all of
 the libraries that get installed into lib/ into the second argument of
 fixup_bundle().

There is no scanning the file system to find which libraries to fix up.
Any libraries used by executables will be considered in the set of libraries 
to fix up, regardless of where they are installed (in bin/ or lib/).  Any 
libraries not found as a dependency can be specified by the second parameter of 
fixup_bundle().  Plugins are a typical example of that, because executables and 
libraries don't link against plugins.

You don't need to add your libraries to the second parameter.  If you did, 
you'd have to know them all up front, and that defeats one of the purpose of 
BundleUtilities.

 
  But after those fixes... there is another error that says:
  Install or copy the item into the bundle before calling fixup_bundle.
  Or maybe there's a typo or incorrect path in one of the args to
  fixup_bundle?
  
  I thought that check applied only to parameters passed in the second
  argument of fixup_bundle(), so that looks like a bug.  That function is
  also only called on Mac if that helps explain some behavior you are
  seeing.
  If I comment out the FATAL_ERROR it issues, then it completes and gives a
  working installation.  Would you like to file a bug report for this?
 
 I went ahead and file a bug report describing my issue:
 http://public.kitware.com/Bug/view.php?id=12382
 
 However, in response to your remark that I thought that check applied
 only to parameters passed in the second argument, consider that even if
 this were true then there would still be a problem.  To see why,
 consider the following example (again, all sources attached to this
 e-mail):
 
 = CMakeLists.txt =
 cmake_minimum_required(VERSION 2.8.5)
 
 set(CMAKE_INSTALL_PREFIX ${CMAKE_BINARY_DIR}/bundle)
 
 add_executable(hello hello)
 add_library(hellolib SHARED hellolib)
 install (TARGETS hello DESTINATION bin)
 install (TARGETS hellolib DESTINATION lib)
 
 configure_file(
  ${CMAKE_SOURCE_DIR}/FixBundle.cmake.in
  ${CMAKE_BINARY_DIR}/FixBundle.cmake
  @ONLY
 )
 install(SCRIPT ${CMAKE_BINARY_DIR}/FixBundle.cmake)
 
 = FixBundle.cmake.in =
 include (BundleUtilities)
 
 fixup_bundle(
${CMAKE_INSTALL_PREFIX}/bin/hello@CMAKE_EXECUTABLE_SUFFIX@
 
 ${CMAKE_INSTALL_PREFIX}/lib/@CMAKE_SHARED_LIBRARY_PREFIX@hellolib@CMAKE_SH
 ARED_LIBRARY_SUFFIX@ @LIBRARY_OUTPUT_PATH@
 )
 
 =
 
 The resulting error message is
 
 =
 -- Install configuration: 
 -- Up-to-date:
 /Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/bin/
 hello -- Installing:
 /Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/lib/
 libhellolib.dylib -- fixup_bundle
 --
 app='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle
 /bin/hello' --
 libs='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundl
 e/lib/libhellolib.dylib' --   dirs=''
 -- fixup_bundle: preparing...
 -- fixup_bundle: copying...
 -- 1/4: *NOT* copying
 '/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/lib
 /libhellolib.dylib' -- 2/4: *NOT* copying
 '/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/bin
 /hello' -- fixup_bundle: fixing...
 -- 3/4: fixing up
 '/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/build/bundle/lib
 /libhellolib.dylib'
 
 exe_dotapp_dir/='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/
 build/bundle/bin/'
 
 item_substring='/Users/gcross/Documents/ThrowawayCode/cmake-issue-example/b
 uild/bundle/lib/'
 
 resolved_embedded_item='/Users/gcross/Documents/ThrowawayCode/cmake-issue-e
 xample/build/bundle/lib/libhellolib.dylib'
 
 Install or copy the item into the bundle before calling fixup_bundle.
 Or maybe there's a typo or incorrect path in one of the args to
 fixup_bundle?
 
 CMake Error at /Applications/CMake
 2.8-5.app/Contents/share/cmake-2.8/Modules/BundleUtilities.cmake:568
 (message):
cannot fixup an item that is not in the bundle...
 Call

Re: [CMake] Gathering up required shared libraries


On 8/2/11 4:32 PM, Clinton Stimpson wrote:

There is no scanning the file system to find which libraries to fix up.
Any libraries used by executables will be considered in the set of libraries
to fix up, regardless of where they are installed (in bin/ or lib/).  Any
libraries not found as a dependency can be specified by the second parameter of
fixup_bundle().  Plugins are a typical example of that, because executables and
libraries don't link against plugins.


Doh!  For some reason I thought I saw that the code was doing that but I 
see now that I was mistaken.



You don't need to add your libraries to the second parameter.  If you did,
you'd have to know them all up front, and that defeats one of the purpose of
BundleUtilities.


Sorry, I obviously didn't make it clear that I was referring to 
libraries that I was not planning on linking the program against --- 
that is, libraries provided for the benefit of other developers but not 
actually used by my program.  Having said that, discussing this has made 
me realize that in my case it would probably make more sense for me to 
link against my own shared library anyway to prevent code from being 
duplicated in both program and library, so my use case is not as likely 
as I had been originally imagining.



If you copy BundleUtilities/GetPrerequisites and remove the FATAL_ERROR
issued.  Then the installation is fixed up correctly, including the libraries
in lib/.  The fix for this bug is to modify that error check.



Okidoke, that sounds easy, and you obviously know what's going on better 
than me so I'll just run with that solution until it gets fixed in the 
mainline.


Thank you very much for your help!!!  :-)

Cheers,
Greg
___
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] Gathering up required shared libraries


On Aug 2, 2011, at 5:47 PM, Gregory Crosswhite wrote:

 On 8/2/11 4:32 PM, Clinton Stimpson wrote:
 There is no scanning the file system to find which libraries to fix up.
 Any libraries used by executables will be considered in the set of libraries
 to fix up, regardless of where they are installed (in bin/ or lib/).  Any
 libraries not found as a dependency can be specified by the second parameter 
 of
 fixup_bundle().  Plugins are a typical example of that, because executables 
 and
 libraries don't link against plugins.
 
 Doh!  For some reason I thought I saw that the code was doing that but I see 
 now that I was mistaken.
 
 You don't need to add your libraries to the second parameter.  If you did,
 you'd have to know them all up front, and that defeats one of the purpose of
 BundleUtilities.
 
 Sorry, I obviously didn't make it clear that I was referring to libraries 
 that I was not planning on linking the program against --- that is, libraries 
 provided for the benefit of other developers but not actually used by my 
 program.  Having said that, discussing this has made me realize that in my 
 case it would probably make more sense for me to link against my own shared 
 library anyway to prevent code from being duplicated in both program and 
 library, so my use case is not as likely as I had been originally imagining.

Oh, so you're also providing libraries for other developers.  In that case, you 
do specify them into the second parameter of fixup_bundle().  If those 
libraries have additional dependencies, then BundleUtilities could be useful 
for that.

Clint
___
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] Gathering up required shared libraries

On Tue, Aug 2, 2011 at 8:05 PM, Clinton Stimpson clin...@elemtech.com wrote:

 On Aug 2, 2011, at 5:47 PM, Gregory Crosswhite wrote:

 On 8/2/11 4:32 PM, Clinton Stimpson wrote:
 There is no scanning the file system to find which libraries to fix up.
 Any libraries used by executables will be considered in the set of libraries
 to fix up, regardless of where they are installed (in bin/ or lib/).  Any
 libraries not found as a dependency can be specified by the second 
 parameter of
 fixup_bundle().  Plugins are a typical example of that, because executables 
 and
 libraries don't link against plugins.

 Doh!  For some reason I thought I saw that the code was doing that but I see 
 now that I was mistaken.

 You don't need to add your libraries to the second parameter.  If you did,
 you'd have to know them all up front, and that defeats one of the purpose of
 BundleUtilities.

 Sorry, I obviously didn't make it clear that I was referring to libraries 
 that I was not planning on linking the program against --- that is, 
 libraries provided for the benefit of other developers but not actually used 
 by my program.  Having said that, discussing this has made me realize that 
 in my case it would probably make more sense for me to link against my own 
 shared library anyway to prevent code from being duplicated in both program 
 and library, so my use case is not as likely as I had been originally 
 imagining.

 Oh, so you're also providing libraries for other developers.  In that case, 
 you do specify them into the second parameter of fixup_bundle().  If those 
 libraries have additional dependencies, then BundleUtilities could be useful 
 for that.

 Clint
 ___
 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


Let's not lose sight of the intent behind fixup_bundle here. I don't
want to confuse things by trying to make it all things to all people.

For our purposes, a bundle is a relocatable file system entity (a
directory) which contains a set of executables and libraries that
after fixup, are entirely self-contained, referring to each other only
by relative paths, and will work on any compatible OS, regardless of
where they are placed in the target file system.

On the Mac, this is achieved by copying external libraries into the
bundle and fixing up their references. Elsewhere, this is typically
achieved by copying libraries into the same directory with the
executable (on Windows, just works, on Linux, works as long as you use
$ORIGIN RPATH references).

When you do not have a .app directory, and you are not copying into
the same directory with the executable, then the question in my mind
becomes what exactly is 'the bundle' at this point?

With a dir/bin, dir/lib typical Linux style layout, dir would be
the bundle...

If we really want to support this, perhaps we need another function to
extend fixup_bundle so that you pass in the bundle's directory, and
its main executable, or a list of executables. Instead of trying to
derive it from just the main executable like we do now.


David C.
___
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] Gathering up required shared libraries

On 08/02/2011 05:36 PM, David Cole wrote:
 When you do not have a .app directory, and you are not copying into
 the same directory with the executable, then the question in my mind
 becomes what exactly is 'the bundle' at this point?

 With a dir/bin, dir/lib typical Linux style layout, dir would be
 the bundle...

 If we really want to support this, perhaps we need another function to
 extend fixup_bundle so that you pass in the bundle's directory, and
 its main executable, or a list of executables. Instead of trying to
 derive it from just the main executable like we do now.


 David C.

For what my two cents are worth, I think that this is a great idea and
would be incredibly helpful, though again I will not claim to be an
expert here.  :-)

Cheers,
Greg
___
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.5-1389-g9f4a135

2011-08-02 Thread Will Dicharry

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  9f4a135dc1050d2f01f222d1ea418882a196b7b1 (commit)
   via  ad218e435d0f25d2022dc2d7b569ad88d10dc6d1 (commit)
   via  d8c1b44790ee2d6fce56c327e639407456f6c61c (commit)
  from  d4eb84d0efba4801d3411565d96fb7a66c4481b6 (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=9f4a135dc1050d2f01f222d1ea418882a196b7b1
commit 9f4a135dc1050d2f01f222d1ea418882a196b7b1
Merge: d4eb84d ad218e4
Author: Will Dicharry wdicha...@stellarscience.com
AuthorDate: Tue Aug 2 12:51:45 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 12:51:45 2011 -0400

Merge topic 'hdf5-module-12316-fix' into next

ad218e4 Added HDF5 high level Fortran bindings to available components.
d8c1b44 KWSys Nightly Date Stamp


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad218e435d0f25d2022dc2d7b569ad88d10dc6d1
commit ad218e435d0f25d2022dc2d7b569ad88d10dc6d1
Author: Will Dicharry wdicha...@stellarscience.com
AuthorDate: Tue Aug 2 10:39:04 2011 -0600
Commit: Will Dicharry wdicha...@stellarscience.com
CommitDate: Tue Aug 2 10:48:14 2011 -0600

Added HDF5 high level Fortran bindings to available components.

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index 6f01ea0..bc60638 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -10,8 +10,8 @@
 # are specified, then the find module will default to finding only the HDF5 C
 # library.  If one or more COMPONENTS are specified, the module will attempt to
 # find the language bindings for the specified components.  The only valid
-# components are C, CXX, Fortran, and HL.  If the COMPONENTS argument is not
-# given, the module will attempt to find only the C bindings.
+# components are C, CXX, Fortran, HL, and Fortran_HL.  If the COMPONENTS
+# argument is not given, the module will attempt to find only the C bindings.
 #
 # On UNIX systems, this module will read the variable HDF5_USE_STATIC_LIBRARIES
 # to determine whether or not to prefer a static link to a dynamic link for 
HDF5
@@ -34,6 +34,8 @@
 #  HDF5_CXX_LIBRARIES - Required libraries for the HDF5 C++ bindings
 #  HDF5_Fortran_LIBRARIES - Required libraries for the HDF5 Fortran bindings
 #  HDF5_HL_LIBRARIES - Required libraries for the HDF5 high level API
+#  HDF5_Fortran_HL_LIBRARIES - Required libraries for the high level Fortran
+#  bindings.
 #  HDF5_LIBRARIES - Required libraries for all requested bindings
 #  HDF5_FOUND - true if HDF5 was found on the system
 #  HDF5_LIBRARY_DIRS - the full set of library directories
@@ -67,6 +69,7 @@ set( HDF5_VALID_COMPONENTS
 CXX
 Fortran
 HL
+Fortran_HL
 )
 
 # Validate the list of find components.
@@ -189,6 +192,7 @@ if( NOT HDF5_FOUND )
 set( HDF5_CXX_TARGET hdf5_cpp )
 set( HDF5_HL_TARGET hdf5_hl )
 set( HDF5_Fortran_TARGET hdf5_fortran )
+set( HDF5_Fortran_HL_TARGET hdf5_hl_fortran )
 foreach( _component ${HDF5_LANGUAGE_BINDINGS} )
 list( FIND HDF5_VALID_COMPONENTS ${_component} _component_location 
)
 get_target_property( _comp_location ${HDF5_${_component}_TARGET} 
LOCATION )
@@ -211,7 +215,10 @@ if( NOT HDF5_FOUND )
 set( HDF5_C_LIBRARY_NAMES_INIT hdf5 )
 set( HDF5_HL_LIBRARY_NAMES_INIT hdf5_hl ${HDF5_C_LIBRARY_NAMES_INIT} )
 set( HDF5_CXX_LIBRARY_NAMES_INIT hdf5_cpp ${HDF5_C_LIBRARY_NAMES_INIT} )
-set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran 
${HDF5_C_LIBRARY_NAMES_INIT} )
+set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran
+${HDF5_C_LIBRARY_NAMES_INIT} )
+set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran
+${HDF5_Fortran_LIBRARY_NAMES_INIT} )
 
 foreach( LANGUAGE ${HDF5_LANGUAGE_BINDINGS} )
 if( HDF5_${LANGUAGE}_COMPILE_LINE )
@@ -222,8 +229,8 @@ if( NOT HDF5_FOUND )
 HDF5_${LANGUAGE}_LIBRARY_NAMES
 )
 
-# take a guess that the includes may be in the 'include' sibling 
directory
-# of a library directory.
+# take a guess that the includes may be in the 'include' sibling
+# directory of a library directory.
 foreach( dir ${HDF5_${LANGUAGE}_LIBRARY_DIRS} )
 list( APPEND HDF5_${LANGUAGE}_INCLUDE_FLAGS ${dir}/../include )
 endforeach()
@@ -233,7 +240,7 @@ if( NOT HDF5_FOUND )
 list( APPEND HDF5_DEFINITIONS ${HDF5_${LANGUAGE}_DEFINITIONS} )
 
 # find the HDF5 include directories
-if(${LANGUAGE} STREQUAL Fortran)
+if(${LANGUAGE}

[Cmake-commits] CMake branch, master, updated. v2.8.5-87-g2c7b38a

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  2c7b38afa6e941166501dfed47e6b22b1847b9ab (commit)
   via  b62349cc60d71eb2af5648eb6867678d5b05273b (commit)
   via  f366cf8a86a1e403b5922bb5bfa2488460f49201 (commit)
   via  f407bb5da29b36ca4edee93ff21ae2a5b8fda960 (commit)
   via  02d47abe58b4fa99f34b24cb799084e0f57215bd (commit)
   via  91a1527735c8d4f598a1836b1cc8ba128936712e (commit)
   via  0671a029205763845e5fd21ce5f69fbe8b0b2c45 (commit)
   via  aae13f4c8ea652f437b096b9017bd76ed62fd44d (commit)
  from  d8c1b44790ee2d6fce56c327e639407456f6c61c (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=2c7b38afa6e941166501dfed47e6b22b1847b9ab
commit 2c7b38afa6e941166501dfed47e6b22b1847b9ab
Merge: d8c1b44 b62349c
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:09:41 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:09:41 2011 -0400

Merge topic 'FeatureSummaryImprovements'

b62349c FeatureSummary.cmake: update documentation
f366cf8 FeatureSummary.cmake: cosmetics
f407bb5 FeatureSummary.cmake: only higher TYPEs can override previous TYPEs
02d47ab FeatureSummary.cmake: error out when a REQUIRED package is missing
91a1527 FeatureSummary.cmake: add INCLUDE_QUIET_PACKAGES keyword
0671a02 FeatureSummary.cmake: remove comment field
aae13f4 Extend FeatureSummary: add PURPOSE of package and TYPE


---

Summary of changes:
 Modules/FeatureSummary.cmake|  391 +++
 Source/cmFindPackageCommand.cxx |   16 +-
 2 files changed, 320 insertions(+), 87 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, master, updated. v2.8.5-89-gc6051b7

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  c6051b7abd093707ad3779a9a29cbf772355e8f5 (commit)
   via  317d077f6ed05640f86efbcb5c34d776a4ad9590 (commit)
  from  2c7b38afa6e941166501dfed47e6b22b1847b9ab (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=c6051b7abd093707ad3779a9a29cbf772355e8f5
commit c6051b7abd093707ad3779a9a29cbf772355e8f5
Merge: 2c7b38a 317d077
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:09:45 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:09:45 2011 -0400

Merge topic 'library-multiarch-issue-12326'

317d077 multiarch: Treat lib/arch as implicit link dir (#12326)


---

Summary of changes:
 Source/cmComputeLinkInformation.cxx |   12 
 1 files changed, 12 insertions(+), 0 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, master, updated. v2.8.5-91-gbe3ac14

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  be3ac14ac707b4d2973ca9854450b849c0968e83 (commit)
   via  b7f3f7cdb62fcadba806aca8168c88a9a637eda6 (commit)
  from  c6051b7abd093707ad3779a9a29cbf772355e8f5 (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=be3ac14ac707b4d2973ca9854450b849c0968e83
commit be3ac14ac707b4d2973ca9854450b849c0968e83
Merge: c6051b7 b7f3f7c
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:09:49 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:09:49 2011 -0400

Merge topic 'add-flag-detection-regex'

b7f3f7c Add fail regex to detect supported warning flags correctly.


---

Summary of changes:
 Modules/CheckCCompilerFlag.cmake |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, master, updated. v2.8.5-93-g39faba7

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  39faba7e30151a6c884d2ec38932235223b9821d (commit)
   via  acd2f84cc0bba33e7f781420189d511586a310b1 (commit)
  from  be3ac14ac707b4d2973ca9854450b849c0968e83 (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=39faba7e30151a6c884d2ec38932235223b9821d
commit 39faba7e30151a6c884d2ec38932235223b9821d
Merge: be3ac14 acd2f84
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:09:53 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:09:53 2011 -0400

Merge topic 'cmSystemTools-whitespace'

acd2f84 cmSystemTools: Remove trailing whitespace


---

Summary of changes:
 Source/cmSystemTools.cxx |  162 +++---
 Source/cmSystemTools.h   |   74 +++---
 2 files changed, 118 insertions(+), 118 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, master, updated. v2.8.5-98-g2444d6f

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  2444d6f55eb0e66893c0e86b10e466ceaae32e31 (commit)
   via  a343bc1c764c87b20edbdf960d870fd4b084ce8a (commit)
   via  642f10066a5c9b33e8736b9ca013a44023c21b2c (commit)
   via  856a9e499f299a33cb4f763bf36a75524a03e4f5 (commit)
   via  4096066723ec7dd6f450e1c8da13616c0ca2f124 (commit)
  from  39faba7e30151a6c884d2ec38932235223b9821d (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=2444d6f55eb0e66893c0e86b10e466ceaae32e31
commit 2444d6f55eb0e66893c0e86b10e466ceaae32e31
Merge: 39faba7 a343bc1
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:09:57 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:09:57 2011 -0400

Merge topic 'split-stdout-stderr'

a343bc1 RunSingleCommand: Avoid assignment in condition
642f100 RunSingleCommand: Add a OUTPUT_NORMAL flag.
856a9e4 RunSingleCommand: Replace verbose boolean with enum
4096066 RunSingleCommand: Fix indentation


---

Summary of changes:
 Source/CPack/cmCPackGenerator.cxx  |2 +-
 Source/CPack/cmCPackGenerator.h|7 ++-
 Source/CPack/cmCPackNSISGenerator.cxx  |3 +-
 Source/CTest/cmCTestGenericHandler.cxx |2 +-
 Source/CTest/cmCTestGenericHandler.h   |7 ++-
 Source/CTest/cmCTestTestHandler.cxx|3 +-
 Source/cmGlobalGenerator.cxx   |6 +-
 Source/cmGlobalGenerator.h |5 +-
 Source/cmSiteNameCommand.cxx   |2 +-
 Source/cmSystemTools.cxx   |   74 ---
 Source/cmSystemTools.h |   23 +++---
 Source/cmTryRunCommand.cxx |2 +-
 Source/cmake.cxx   |9 ++--
 Source/cmake.h |3 +-
 Source/cmakemain.cxx   |8 +++-
 15 files changed, 103 insertions(+), 53 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, master, updated. v2.8.5-100-g996eb50

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  996eb5036458338371acb22b7ac25e88d5f9f0f8 (commit)
   via  6b71bf88766ac968a389f2813f8f9244e3f561b4 (commit)
  from  2444d6f55eb0e66893c0e86b10e466ceaae32e31 (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=996eb5036458338371acb22b7ac25e88d5f9f0f8
commit 996eb5036458338371acb22b7ac25e88d5f9f0f8
Merge: 2444d6f 6b71bf8
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:10:01 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:10:01 2011 -0400

Merge topic 'RemoveDebugOutput'

6b71bf8 Remove debug output from CheckSymbolExists


---

Summary of changes:
 Modules/CheckSymbolExists.cmake |1 -
 1 files changed, 0 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, master, updated. v2.8.5-102-g7ef2f53

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  7ef2f53d02869c397ca1555781c3661a7519a9dc (commit)
   via  de30173d5b39d645f059272857054d1f80165141 (commit)
  from  996eb5036458338371acb22b7ac25e88d5f9f0f8 (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=7ef2f53d02869c397ca1555781c3661a7519a9dc
commit 7ef2f53d02869c397ca1555781c3661a7519a9dc
Merge: 996eb50 de30173
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:10:05 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:10:05 2011 -0400

Merge topic 'qt4-use-check-cxx-symbol'

de30173 Remove C compiler requirement from FindQt4.cmake


---

Summary of changes:
 Modules/FindQt4.cmake |   14 +++---
 1 files changed, 7 insertions(+), 7 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, master, updated. v2.8.5-104-g86bae62

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  86bae62bd1a3369a1487887392d22be39530a2bd (commit)
   via  df9577259ca5a30f5c79baee038fe42e25b4a1e5 (commit)
  from  7ef2f53d02869c397ca1555781c3661a7519a9dc (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=86bae62bd1a3369a1487887392d22be39530a2bd
commit 86bae62bd1a3369a1487887392d22be39530a2bd
Merge: 7ef2f53 df95772
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:10:09 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:10:09 2011 -0400

Merge topic 'fix-8707-add-vs-globals'

df95772 Add support for Visual Studio project-specific globals (#8707)


---

Summary of changes:
 Source/cmLocalVisualStudio7Generator.cxx |   26 ++
 Source/cmLocalVisualStudio7Generator.h   |2 +-
 Source/cmSetTargetPropertiesCommand.h|4 
 Source/cmTarget.cxx  |8 
 Tests/VSResource/CMakeLists.txt  |5 -
 5 files changed, 39 insertions(+), 6 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, master, updated. v2.8.5-106-g330577c

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  330577ce875568bc0906ac08cd6c2a638ab503eb (commit)
   via  0375865a4e1ab337ae5ac2e8eae888444da00864 (commit)
  from  86bae62bd1a3369a1487887392d22be39530a2bd (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=330577ce875568bc0906ac08cd6c2a638ab503eb
commit 330577ce875568bc0906ac08cd6c2a638ab503eb
Merge: 86bae62 0375865
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:10:12 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:10:12 2011 -0400

Merge topic 'fix-updategit-test'

0375865 Fix machine-specific UpdateGIT test failures


---

Summary of changes:
 Tests/CTestUpdateCommon.cmake |8 +---
 1 files changed, 5 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, master, updated. v2.8.5-108-g7824885

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  782488596062649703919066cd1a84f05fd24e18 (commit)
   via  0baf5659c6222175b5d0a5b47d45e145dbdb8400 (commit)
  from  330577ce875568bc0906ac08cd6c2a638ab503eb (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=782488596062649703919066cd1a84f05fd24e18
commit 782488596062649703919066cd1a84f05fd24e18
Merge: 330577c 0baf565
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:10:15 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:10:15 2011 -0400

Merge topic 'adjust-path-for-all-generators-test'

0baf565 Ensure libgmp-10.dll is in the PATH for CMakeTestAllGenerators


---

Summary of changes:
 Tests/CMakeTestAllGenerators/RunCMake.cmake |   22 ++
 1 files changed, 22 insertions(+), 0 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, master, updated. v2.8.5-112-gabc8586

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  abc85867169a92f189d6378e95d062f24aa1bd93 (commit)
   via  05ddfbfe95c4536521084975be6e9cadf0ee05f9 (commit)
  from  b01167161c379dcd0dfdb56346fd3caf61ff0189 (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=abc85867169a92f189d6378e95d062f24aa1bd93
commit abc85867169a92f189d6378e95d062f24aa1bd93
Merge: b011671 05ddfbf
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:10:31 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:10:31 2011 -0400

Merge topic 'fix-12299-add-vs10-scc-support'

05ddfbf VS10: Add SCC support


---

Summary of changes:
 Source/cmVisualStudio10TargetGenerator.cxx |   19 +--
 1 files changed, 17 insertions(+), 2 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, master, updated. v2.8.5-116-ge9a6d86

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  e9a6d86d91451468e4a4bf52e8cd23199362bffa (commit)
   via  f32f6f0652b8b99abd2cf8558a193571e47e9217 (commit)
  from  ab24bdeecc985f197d637cb593008ae29ae882cb (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=e9a6d86d91451468e4a4bf52e8cd23199362bffa
commit e9a6d86d91451468e4a4bf52e8cd23199362bffa
Merge: ab24bde f32f6f0
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:11:01 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:11:01 2011 -0400

Merge topic 'ExcludeCMakesFilesFromCodeBlocksProject'

f32f6f0 Don't put files from CMAKE_ROOT into CodeBlocks projects (#12110)


---

Summary of changes:
 Source/cmExtraCodeBlocksGenerator.cxx |7 +++
 1 files changed, 7 insertions(+), 0 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, master, updated. v2.8.5-118-g11ca173

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  11ca173731a73b9635a0ebc2a16e116931e9de7a (commit)
   via  1f641de4b8cad556f8f4139ac7abe198364c0b8b (commit)
  from  e9a6d86d91451468e4a4bf52e8cd23199362bffa (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=11ca173731a73b9635a0ebc2a16e116931e9de7a
commit 11ca173731a73b9635a0ebc2a16e116931e9de7a
Merge: e9a6d86 1f641de
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:11:20 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:11:20 2011 -0400

Merge topic 'doc-WIN32-cygwin'

1f641de Documentation: WIN32 not defined on Cygwin (#12334)


---

Summary of changes:
 Source/cmDocumentVariables.cxx |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, master, updated. v2.8.5-121-gbd54141

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  bd54141d5d098899afa36c6326811eb2230e99cf (commit)
   via  ff5971635170af8754edb029b5345e17fb4de4fa (commit)
   via  80769cdd1e568c1dbc66651557d98bba0f70ea00 (commit)
  from  11ca173731a73b9635a0ebc2a16e116931e9de7a (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=bd54141d5d098899afa36c6326811eb2230e99cf
commit bd54141d5d098899afa36c6326811eb2230e99cf
Merge: 11ca173 ff59716
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:11:35 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:11:35 2011 -0400

Merge topic 'fix-11866-add-watcom-sys-libs'

ff59716 Watcom: Use correct args for execute_process call (#11866)
80769cd Add Watcom support to InstallRequiredSystemLibraries (#11866)


---

Summary of changes:
 Modules/CMakeTestWatcomVersion.c |1 +
 Modules/InstallRequiredSystemLibraries.cmake |   34 +++
 Modules/Platform/Windows-wcl386.cmake|   38 ++
 3 files changed, 73 insertions(+), 0 deletions(-)
 create mode 100644 Modules/CMakeTestWatcomVersion.c


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.5-126-g737be8f

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  737be8f6f65007bcc8cd3fa6d72288264d05e1ba (commit)
   via  825c45739d888cd5fe43875a9e0497c7b389ae70 (commit)
   via  e159bb5bf80eba01d2244e2ef1333b145c2375fe (commit)
   via  da1bdaf16a60d3822f15feb1b1a9d624ae357705 (commit)
   via  217d068b6d131247b1fbae1ec901c942b30f7f80 (commit)
  from  bd54141d5d098899afa36c6326811eb2230e99cf (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=737be8f6f65007bcc8cd3fa6d72288264d05e1ba
commit 737be8f6f65007bcc8cd3fa6d72288264d05e1ba
Merge: bd54141 825c457
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:11:45 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:11:45 2011 -0400

Merge topic 'FindPostgresqlImprovements'

825c457 FindPostgreSQL: fix PATH_SUFFIXES, better output for FPHSA
e159bb5 Mark the results from find() as advanced
da1bdaf Use FPHSA(), remove unnecessary stuff and don't recommend 
link_directories()
217d068 More PATH_SUFFIXES for finding Postgresql and also search 
catalog/pg_type.h


---

Summary of changes:
 Modules/FindPostgreSQL.cmake |   53 ++---
 1 files changed, 23 insertions(+), 30 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, master, updated. v2.8.5-131-g6a11727

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  6a117271545d40b7d9615e840ba89d959e0b758d (commit)
   via  81a70c6ad2b13b6a196330767316d1aac5d3ece6 (commit)
   via  2462f6508564a5e7b1a56255a480303f11e680b4 (commit)
   via  f97620e733a0939046b5b098da3451b20fd26c96 (commit)
   via  7c3852347082a4a0fbeab747d0ec975b72a13c27 (commit)
  from  737be8f6f65007bcc8cd3fa6d72288264d05e1ba (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=6a117271545d40b7d9615e840ba89d959e0b758d
commit 6a117271545d40b7d9615e840ba89d959e0b758d
Merge: 737be8f 81a70c6
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:11:53 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:11:53 2011 -0400

Merge topic 'FindGIFAndFreetypeCleanupAndEnhancements'

81a70c6 Add basic version check for giflib
2462f65 FindGif: add giflib4 as one more name for the library under Windows
f97620e FindGIF/FindFreetype.cmake: remove standard search paths from 
find-calls
7c38523 Strip trailing whitespace


---

Summary of changes:
 Modules/FindFreetype.cmake |   25 ++--
 Modules/FindGIF.cmake  |   52 +++
 2 files changed, 41 insertions(+), 36 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, master, updated. v2.8.5-135-g80ef23d

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  80ef23d83fbf534bb3488db69a284fedf2be17e4 (commit)
   via  e2e8c0a41225f5449a8139a1ce0219940f902665 (commit)
   via  92c0dc50fc73dd9866f48c521b0aff7473eb3a59 (commit)
   via  a5683f80bdc1c8c78d8db47f5695e0be3cc19afe (commit)
  from  6a117271545d40b7d9615e840ba89d959e0b758d (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=80ef23d83fbf534bb3488db69a284fedf2be17e4
commit 80ef23d83fbf534bb3488db69a284fedf2be17e4
Merge: 6a11727 e2e8c0a
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Aug 2 15:11:58 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Aug 2 15:11:58 2011 -0400

Merge topic 'CodeBlocksIncludeDirsAndDefines'

e2e8c0a Also put builtin include dirs into CodeBlocks project file
92c0dc5 Remove useless line of code
a5683f8 Patch by Campbell Barton: puts definitions into C::B project file


---

Summary of changes:
 ...torDetermineCompilerMacrosAndIncludeDirs.cmake} |   54 --
 Modules/CMakeFindCodeBlocks.cmake  |2 +
 Modules/CMakeFindEclipseCDT4.cmake |  104 +---
 Source/cmExtraCodeBlocksGenerator.cxx  |   54 ++
 Source/cmExtraEclipseCDT4Generator.cxx |   10 +-
 5 files changed, 85 insertions(+), 139 deletions(-)
 copy Modules/{CMakeFindEclipseCDT4.cmake = 
CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake} (65%)


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.5-1409-g000074e