Re: [CMake] CMake 2.8.3-rc4 ready for testing!

2010-11-04 Thread Eric Noulard
2010/11/4 Bill Hoffman bill.hoff...@kitware.com:
 But, for now, you should be able to work around it on your side by
 removing the sha.1 from the list of files in your
 set_source_files_properties call.

 True just tested that. It works.

 I meant ...removing the sha1.h from ...

 I inferred that too :-)


 If you don't want that file to be compiled, then setting the language to C
 is wrong, and is likely to produce unexpected behavior.  It is telling CMake
 that the file is a C file and it should be compiled. CMake should of course
 not create a VS project that fails to load because of this, but it might do
 other odd things when you try and treat a .h file like it is a .c file.

Ok I get it, but note that I had a semantic issue.

This project is a C++ project with some C files.
There are both headers AND source file.

In my mind  source file may either be a header or a body (i.e.) to
be compiled file.
So  I wazs trying to tell CMake that this header is a C one in order to be
consistent.

The set_source_files_properties says :
Set properties on a file.
and later on:

LANGUAGE (string) CXX|C will change the default compiler used to
compile the source file.

now I get that a source file is-a to be compiled file.

So my mistake may be was an english understanding  issue of what is
a source file.

I continue to think that it would be valuable to tell CMake that such header
is a C/Fortran/CXX woiuld be nice.

It may even become necessary if pre-compiled header are to be supported.

So I now understand my mistake but I'm not on your side when you say
setting the language to C is wrong

I think it should be just OK, setting the LANGUAGE of a file shouldn't imply
this file has to be compiled.

-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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] CMake 2.8.3-rc4 ready for testing!

2010-11-03 Thread Eric Noulard
2010/10/30 David Cole david.c...@kitware.com:
 The CMake 2.8.3 release candidate stream continues!
 You can find the source and binaries here:
 http://www.cmake.org/files/v2.8/?C=M;O=D

 EXCEPT: There are not yet Irix or Sun pre-built binary
 installers available for CMake 2.8.3-rc4. There is a
 failing (HTML documentation validity checking) test on
 some platforms that appears to be unrelated to any CMake
 source code changes. That test failure is preventing the
 release building process from completing today on those
 platforms. If that issue clears up soon, I'll re-do the
 installers on those platforms. If not, just use rc3, or
 build from source. We'll address this before the final
 release.

 This will be the LAST release candidate for 2.8.3
 unless a major regression is reported. So please
 try it on your projects and let us know right away
 about any problems.

I may have a problem with Visual Studio 2010 generator.
The concerned project CERTI (https://savannah.nongnu.org/projects/certi)
builds fine on on several using CMake.

But when we try to build CERTI with CMake 2.8.2 (or 2.8.3rc4) we get
a solution file which fails to load completely because because one vcproj
contains an apparently mis-closed statement:

offending lines are those one:
[...]
None Include=..\..\certi-HEAD\libHLA\HLAvariantRecord.hh /
ClInclude Include=..\..\certi-HEAD\libHLA\sha1.h
  ObjectFileName$(IntDir)/sha1.obj/ObjectFileName
/ClCompile
None Include=..\..\certi-HEAD\libHLA\Clock.hh /
[...]

i.e. the ClInclude Include ...
is closed by a
   /ClCompile

The corresponding source code may be found there:
http://cvs.savannah.gnu.org/viewvc/certi/?root=certi.

I'm not sure I will have the time to build a smaller example.

Note that the same source tree is working well using any
other CMake generators (Visual Studio or Code::Blocks etc...)
so the problem seems to be particular to VS2010.



-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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] CMake 2.8.3-rc4 ready for testing!

2010-11-03 Thread Rolf Eike Beer
Am Mittwoch, 3. November 2010 schrieb Eric Noulard:

 I may have a problem with Visual Studio 2010 generator.
 The concerned project CERTI (https://savannah.nongnu.org/projects/certi)
 builds fine on on several using CMake.
 
 But when we try to build CERTI with CMake 2.8.2 (or 2.8.3rc4) we get
 a solution file which fails to load completely because because one vcproj
 contains an apparently mis-closed statement:
 
 offending lines are those one:
 [...]
 None Include=..\..\certi-HEAD\libHLA\HLAvariantRecord.hh /
 ClInclude Include=..\..\certi-HEAD\libHLA\sha1.h
   ObjectFileName$(IntDir)/sha1.obj/ObjectFileName
 /ClCompile
 None Include=..\..\certi-HEAD\libHLA\Clock.hh /
 [...]
 
 i.e. the ClInclude Include ...
 is closed by a
/ClCompile
 
 The corresponding source code may be found there:
 http://cvs.savannah.gnu.org/viewvc/certi/?root=certi.
 
 I'm not sure I will have the time to build a smaller example.
 
 Note that the same source tree is working well using any
 other CMake generators (Visual Studio or Code::Blocks etc...)
 so the problem seems to be particular to VS2010.

Try the attached patch. It's completely untested so it may even not compile 
but that should be pretty straightforward.

Greetings,

Eike
From faa226048c68050cad32726788750fa6252ce9cb Mon Sep 17 00:00:00 2001
From: Rolf Eike Beer e...@sf-mail.de
Date: Wed, 3 Nov 2010 20:07:58 +0100
Subject: [PATCH] fix MSVC2010 generator writing wrong closing tag

---
 Source/cmVisualStudio10TargetGenerator.cxx |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx
index 524be8b..8379d0f 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -689,10 +689,14 @@ void cmVisualStudio10TargetGenerator::WriteCLSources()
 }
   (*this-BuildFileStream )  sourceFile  \;
   // ouput any flags specific to this source file
-  if(cl  this-OutputSourceSpecificFlags(*source))
+  // if the source file has specific flags the tag
+  // is ended on a new line
+  if(header  this-OutputSourceSpecificFlags(*source))
+{
+this-WriteString(/ClInclude\n, 2);
+}
+  else if(cl  this-OutputSourceSpecificFlags(*source))
 {
-// if the source file has specific flags the tag
-// is ended on a new line
 this-WriteString(/ClCompile\n, 2);
 }
   else
-- 
1.7.1



signature.asc
Description: This is a digitally signed message part.
___
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] CMake 2.8.3-rc4 ready for testing!

2010-11-03 Thread Bill Hoffman

On 11/3/2010 3:09 PM, Rolf Eike Beer wrote:

Am Mittwoch, 3. November 2010 schrieb Eric Noulard:


I may have a problem with Visual Studio 2010 generator.
The concerned project CERTI (https://savannah.nongnu.org/projects/certi)
builds fine on on several using CMake.

But when we try to build CERTI with CMake 2.8.2 (or 2.8.3rc4) we get
a solution file which fails to load completely because because one vcproj
contains an apparently mis-closed statement:

offending lines are those one:
[...]
 None Include=..\..\certi-HEAD\libHLA\HLAvariantRecord.hh /
 ClInclude Include=..\..\certi-HEAD\libHLA\sha1.h
   ObjectFileName$(IntDir)/sha1.obj/ObjectFileName
 /ClCompile
 None Include=..\..\certi-HEAD\libHLA\Clock.hh /
[...]

i.e. theClInclude Include ...
is closed by a
/ClCompile

The corresponding source code may be found there:
http://cvs.savannah.gnu.org/viewvc/certi/?root=certi.

I'm not sure I will have the time to build a smaller example.

Note that the same source tree is working well using any
other CMake generators (Visual Studio or Code::Blocks etc...)
so the problem seems to be particular to VS2010.


Try the attached patch. It's completely untested so it may even not compile
but that should be pretty straightforward.



The reason this is showing up is because they are compiling a .h file:

LIST(APPEND LIBHLA_EXPORTED_INCLUDES sha1.h)
set_source_files_properties(sha1.c sha1.h PROPERTIES LANGUAGE C)
SOURCE_GROUP(Source Files\\Hash FILES ${LIBHLA_HASH_SRCS})


The sha1.h is being set to a C source file.  It is a bug, and the patch 
should fix it.  However, seems odd to be compiling a .h file.


-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] CMake 2.8.3-rc4 ready for testing!

2010-11-03 Thread Eric Noulard
2010/11/3 Bill Hoffman bill.hoff...@kitware.com:

 The reason this is showing up is because they are compiling a .h file:

 LIST(APPEND LIBHLA_EXPORTED_INCLUDES sha1.h)
 set_source_files_properties(sha1.c sha1.h PROPERTIES LANGUAGE C)
 SOURCE_GROUP(Source Files\\Hash FILES ${LIBHLA_HASH_SRCS})


 The sha1.h is being set to a C source file.  It is a bug, and the patch
 should fix it.

I'll try the patch.

 However, seems odd to be compiling a .h file.

What do you mean by compiling a header?

I usually do

add_library(mylib file1.c file1.h file2.c file2.h)
or
add_executable(myexe mysource.c anyother.h)
etc...

what's wrong/odd with that I thought CMake would sort it out
what is an header and what is not ?

Or do you mean that the
set_source_files_properties(sha1.c sha1.h PROPERTIES LANGUAGE C)

is telling CMake that sha1.h should be compiled?

I thought I was (because I'm the culprit) telling CMake that thoses file
were C files (either header or to-be-compiled sources)?

Am I wrong?


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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] CMake 2.8.3-rc4 ready for testing!

2010-11-03 Thread David Cole
On Wed, Nov 3, 2010 at 5:09 PM, Eric Noulard eric.noul...@gmail.com wrote:

 2010/11/3 Bill Hoffman bill.hoff...@kitware.com:
 
  The reason this is showing up is because they are compiling a .h file:
 
  LIST(APPEND LIBHLA_EXPORTED_INCLUDES sha1.h)
  set_source_files_properties(sha1.c sha1.h PROPERTIES LANGUAGE C)
  SOURCE_GROUP(Source Files\\Hash FILES ${LIBHLA_HASH_SRCS})
 
 
  The sha1.h is being set to a C source file.  It is a bug, and the patch
  should fix it.

 I'll try the patch.

  However, seems odd to be compiling a .h file.

 What do you mean by compiling a header?

 I usually do

 add_library(mylib file1.c file1.h file2.c file2.h)
 or
 add_executable(myexe mysource.c anyother.h)
 etc...

 what's wrong/odd with that I thought CMake would sort it out
 what is an header and what is not ?

 Or do you mean that the
 set_source_files_properties(sha1.c sha1.h PROPERTIES LANGUAGE C)

 is telling CMake that sha1.h should be compiled?

 I thought I was (because I'm the culprit) telling CMake that thoses file
 were C files (either header or to-be-compiled sources)?

 Am I wrong?


 --
 Erk
 Membre de l'April - « promouvoir et défendre le logiciel libre » -
 http://www.april.org
 ___
 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



It should be fine. CMake should handle .h files that have this property set.
We should fix it. (And we will -- probably in the 2.8.4 release.)

But, for now, you should be able to work around it on your side by removing
the sha.1 from the list of files in your set_source_files_properties call.


HTH,
David
___
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] CMake 2.8.3-rc4 ready for testing!

2010-11-03 Thread Eric Noulard
2010/11/3 David Cole david.c...@kitware.com:

 It should be fine. CMake should handle .h files that have this property
 set. We should fix it. (And we will -- probably in the 2.8.4 release.)

OK no problem.

Sorry for being late to test that combination but I'm not usually
using Windows box
and even more rarely VS2010...

 But, for now, you should be able to work around it on your side by
 removing the sha.1 from the list of files in your
 set_source_files_properties call.

True just tested that. It works.

 I meant ...removing the sha1.h from ...

I inferred that too :-)


-- 
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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] CMake 2.8.3-rc4 ready for testing!

2010-11-03 Thread Bill Hoffman

On 11/3/2010 6:00 PM, Eric Noulard wrote:

2010/11/3 David Coledavid.c...@kitware.com:


It should be fine. CMake should handle .h files that have this property
set. We should fix it. (And we will -- probably in the 2.8.4 release.)


OK no problem.

Sorry for being late to test that combination but I'm not usually
using Windows box
and even more rarely VS2010...


But, for now, you should be able to work around it on your side by
removing the sha.1 from the list of files in your
set_source_files_properties call.


True just tested that. It works.


I meant ...removing the sha1.h from ...


I inferred that too :-)


If you don't want that file to be compiled, then setting the language to 
C is wrong, and is likely to produce unexpected behavior.  It is 
telling CMake that the file is a C file and it should be compiled. 
CMake should of course not create a VS project that fails to load 
because of this, but it might do other odd things when you try and treat 
a .h file like it is a .c file.


-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] CMake 2.8.3-rc4 ready for testing!

2010-11-01 Thread Michael Hertling
On 11/01/2010 01:22 AM, Marcus D. Hanwell wrote:
 On Sun, Oct 31, 2010 at 7:30 PM, Campbell Barton ideasma...@gmail.com wrote:
 Hi I saw in the log you added a case for Python 2.7,
 Would you be able to add a check for Python 3.x ?

 For Blender 3D we use CMake and only support python 3.x series.
 
 I added that (or part of it at least). I suspect it is too late, and
 we really need to add a variable to request Python 3. That would be
 too big of a change this late in the RC series. We could work on
 something, with a view to getting it in CMake 2.8.4, that you could
 add to Blender's CMake module path until the release.
 
 I think for it to be general enough we would need something that
 defaulted to Python 2.x, but could look for Python 3 if the project
 requested it. I was not sure how best to handle this, and wanted to
 make sure this release found Python 2.7. I know for most of the
 project I develop we explicitly don't want Python 3 as our stuff is
 not ready for it yet.

Perhaps, the version parameter of FIND_PACKAGE() can be used for this
purpose. Due to the prevalence of Python 2, one could agree on 2.x as
the default if no version is specified whereas 3.x may be explicitly
requested as FIND_PACKAGE(Python{Interp,Libs} 3 ...). IMO, this is a
more straight approach than introducing additional variables for the
version selection and should mean no harm to backward compatibility.

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] CMake 2.8.3-rc4 ready for testing!

2010-10-31 Thread Campbell Barton
Hi I saw in the log you added a case for Python 2.7,
Would you be able to add a check for Python 3.x ?

For Blender 3D we use CMake and only support python 3.x series.
___
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] CMake 2.8.3-rc4 ready for testing!

2010-10-31 Thread Marcus D. Hanwell
On Sun, Oct 31, 2010 at 7:30 PM, Campbell Barton ideasma...@gmail.com wrote:
 Hi I saw in the log you added a case for Python 2.7,
 Would you be able to add a check for Python 3.x ?

 For Blender 3D we use CMake and only support python 3.x series.

I added that (or part of it at least). I suspect it is too late, and
we really need to add a variable to request Python 3. That would be
too big of a change this late in the RC series. We could work on
something, with a view to getting it in CMake 2.8.4, that you could
add to Blender's CMake module path until the release.

I think for it to be general enough we would need something that
defaulted to Python 2.x, but could look for Python 3 if the project
requested it. I was not sure how best to handle this, and wanted to
make sure this release found Python 2.7. I know for most of the
project I develop we explicitly don't want Python 3 as our stuff is
not ready for it yet.

Marcus
___
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] CMake 2.8.3-rc4 ready for testing!

2010-10-30 Thread Rolf Eike Beer
Am Saturday 30 October 2010 schrieb David Cole:
 The CMake 2.8.3 release candidate stream continues!
 You can find the source and binaries here:
 http://www.cmake.org/files/v2.8/?C=M;O=D

What about http://public.kitware.com/Bug/view.php?id=11326. Alex merged it at 
http://cmake.org/gitweb?p=cmake.git;a=commit;h=cea559d2c4e2c691792da7b95533d717b79241a9
 
into next, it is tagged as 2.8.3 in Mantis but I don't see it in the commit 
logs. I personally don't need this but everyone using Bison on a localized 
system will be left with a broken CMakeCache.txt every time CMake is run.

Eike


signature.asc
Description: This is a digitally signed message part.
___
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] CMake 2.8.3-rc4 ready for testing!

2010-10-30 Thread John Drescher
On Fri, Oct 29, 2010 at 8:57 PM, John Drescher dresche...@gmail.com wrote:
 On Fri, Oct 29, 2010 at 8:17 PM, Karl Wallner cm...@karlwallner.de wrote:
 Am 30.10.2010 00:45, schrieb John Drescher:
 I know its probably too late for 2.8.3 but can someone please look at
 the following bug:
 http://cmake.org/Bug/view.php?id=11206

 This affects me on every single (in house) release of my application.

 Same for this one:
  http://www.cmake.org/Bug/view.php?id=10798

 There is already a patch available.

 I think you have the wrong bug # because that does not appear to have
 anything to do with the generation of NSIS packages.


Sorry. I now see what you were saying. I guess I was tired last evening..

John
___
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] CMake 2.8.3-rc4 ready for testing!

2010-10-29 Thread David Cole
The CMake 2.8.3 release candidate stream continues!
You can find the source and binaries here:
http://www.cmake.org/files/v2.8/?C=M;O=D

EXCEPT: There are not yet Irix or Sun pre-built binary
installers available for CMake 2.8.3-rc4. There is a
failing (HTML documentation validity checking) test on
some platforms that appears to be unrelated to any CMake
source code changes. That test failure is preventing the
release building process from completing today on those
platforms. If that issue clears up soon, I'll re-do the
installers on those platforms. If not, just use rc3, or
build from source. We'll address this before the final
release.

This will be the LAST release candidate for 2.8.3
unless a major regression is reported. So please
try it on your projects and let us know right away
about any problems.

Since we switched to git, and a new workflow, we're
expecting to do more frequent releases. Because of
that, our release candidate phases will be shorter
than they have been historically. So, if you want to
test this out and ask for a fix, do it soon, or hold your
peace till the next release!

Following is the list of changes in this release.
Since we switched to git, this list is now the
'git log' one line summary written by the named
CMake developers.

Please try this version of CMake on your projects
and report any issues to the list or the bug tracker.

Happy building!

-Dave


Changes in CMake 2.8.3-rc4 (since 2.8.3-rc3)

Bill Hoffman (1):
  When processing DartMeasurements use the tests working directory.

David Cole (2):
  ExternalProject: No svn --username if empty (#11173)
  Avoid problem reading jni.h on Macs.

David Partyka (5):
  Fixed appending PATH to dumpbin tool from growing without bounds.
  Switch to CMAKE_PATH when doing PATH comparisons on Windows.
  Remove unecessary TO_CMAKE_PATH for gp_cmd_dir.
  Append the gp_tool path to the system PATH using native slashes.
  Fixes to GetPrerequisites for cygwin

Eric NOULARD (1):
  CPackDeb Added several optional debian binary package fields

Marcus D. Hanwell (2):
  ENH: Added case for Python 2.7.
  Fixed parallel build for generators with EXTRA.

Changes in CMake 2.8.3-rc3 (since 2.8.3-rc2)

Alex Neundorf (4):
  Remove trailing whitespace
  Add automatic variable CMAKE_CURRENT_LIST_DIR(dir of
CMAKE_CURRENT_LIST_FILE)
  Use absolute path to FindPackageHandleStandardArgs.cmake everywhere
  CodeBlocks Generator: Do not omit files in the project file listing.

Brad King (4):
  VS10: Order .vcxproj dependencies deterministically (#10502)
  Document ENABLE_EXPORTS behavior on Mac (#11295)
  FindHDF5: Fix typo in parallel-IO support check (#11291)
  Xcode: Recognize .hh as C++ (#11307)

Clinton Stimpson (1):
  Find imports dir in Qt 4.7

David Partyka (1):
  Update module to locate newely released MS MPI HPC Pack R2.

Philip Lowman (1):
  Remove superfluous variable Boost_COMPAT_STATIC_RUNTIME.

Rolf Eike Beer (2):
  FindSubversion: Fix for German localized client (#11273)
  FindSubversion: Use C locale to detect version (#11273)

Changes in CMake 2.8.3-rc2 (since 2.8.3-rc1)

Alex Neundorf (5):
  APPEND and not-APPEND mode of feature_summary() were swapped
  Set a default DESCRIPTION if none is given for ALL mode of
feature_summary()
  Close ENDFUNCTION() properly with the same name as FUNCTION()
  Make cmake-gui remember whether the Advanced checkbox was checked or not
  Also store the required version number in the details message.

Ben Boeckel (3):
  Add test that CMake errors with empty libs
  Fix which string is checked for in the test
  XCode generation should fail if lang isn't known

Bill Hoffman (5):
  Fix the name of the variable being tested.
  Fix KWStyle line length issues.
  Add a delay after untar on windows to make external project work
on windows 7
  Add a new line to the end of the generated main.cxx for the hpux compiler.
  Fix for bug #11274, VS10 custom commands that create files in INTDIR fix.

Brad King (12):
  Evaluate OBJECT_DIR rule variable for executables
  ccmake: Fix search with '/'
  MinGW: Support long object file lists
  Document IMPORTED_NO_SONAME target property
  FindMPI: Recoginze -f flags from mpicc (#10771)
  Add module-dir flag for Compaq Visual Fortran (#11248)
  FindPythonInterp: Look for python2.7 interpreter
  VS10: Use $(IntDir) for per-source output directory (#11270)
  Reset platform/compiler info status for each language
  Remove trailing whitespace from Xcode generator source
  VS10: Skip targets with no linker language (#11230)
  VS10: Encode custom command comments for echo (#11283)

Clinton Stimpson (1):
  Fix regression in cross-compile patches with finding Qt libs.


Re: [CMake] CMake 2.8.3-rc4 ready for testing!

2010-10-29 Thread John Drescher
On Fri, Oct 29, 2010 at 6:03 PM, David Cole david.c...@kitware.com wrote:
 The CMake 2.8.3 release candidate stream continues!
 You can find the source and binaries here:
 http://www.cmake.org/files/v2.8/?C=M;O=D

 EXCEPT: There are not yet Irix or Sun pre-built binary
 installers available for CMake 2.8.3-rc4. There is a
 failing (HTML documentation validity checking) test on
 some platforms that appears to be unrelated to any CMake
 source code changes. That test failure is preventing the
 release building process from completing today on those
 platforms. If that issue clears up soon, I'll re-do the
 installers on those platforms. If not, just use rc3, or
 build from source. We'll address this before the final
 release.

 This will be the LAST release candidate for 2.8.3
 unless a major regression is reported. So please
 try it on your projects and let us know right away
 about any problems.


I know its probably too late for 2.8.3 but can someone please look at
the following bug:
http://cmake.org/Bug/view.php?id=11206

This affects me on every single (in house) release of my application.

John
___
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] CMake 2.8.3-rc4 ready for testing!

2010-10-29 Thread Karl Wallner

Am 30.10.2010 00:45, schrieb John Drescher:
 I know its probably too late for 2.8.3 but can someone please look at
 the following bug:
 http://cmake.org/Bug/view.php?id=11206

 This affects me on every single (in house) release of my application.

Same for this one:
  http://www.cmake.org/Bug/view.php?id=10798

There is already a patch available.


Regards,

Karl
___
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] CMake 2.8.3-rc4 ready for testing!

2010-10-29 Thread John Drescher
 I know its probably too late for 2.8.3 but can someone please look at
 the following bug:
 http://cmake.org/Bug/view.php?id=11206

 This affects me on every single (in house) release of my application.

 A workaround is to do a monolithic install.
 SET(CPACK_MONOLITHIC_INSTALL 1)
 ...
 INCLUDE(CPack)

 Does that not work for you?

Thanks. I will try that next build..
John
___
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] CMake 2.8.3-rc4 ready for testing!

2010-10-29 Thread John Drescher
On Fri, Oct 29, 2010 at 8:17 PM, Karl Wallner cm...@karlwallner.de wrote:
 Am 30.10.2010 00:45, schrieb John Drescher:
 I know its probably too late for 2.8.3 but can someone please look at
 the following bug:
 http://cmake.org/Bug/view.php?id=11206

 This affects me on every single (in house) release of my application.

 Same for this one:
  http://www.cmake.org/Bug/view.php?id=10798

 There is already a patch available.

I think you have the wrong bug # because that does not appear to have
anything to do with the generation of NSIS packages.

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