[cmake-developers] [CMake 0014225]: cmake -E tar x can manage zip files, this is not documented

2013-06-17 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14225 
== 
Reported By:ycollet
Assigned To:
== 
Project:CMake
Issue ID:   14225
Category:   Documentation
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2013-06-17 10:00 EDT
Last Modified:  2013-06-17 10:00 EDT
== 
Summary:cmake  -E tar x can manage zip files, this is not
documented
Description: 
cmake  -E tar x can manage zip files, this is not documented when I do a cmake
-E.
It is only said that:

tar [cxt][vfz][cvfj] file.tar file/dir1 file/dir2 ... - create a tar archive

You should add create and deflate a tar / zip archive

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-06-17 10:00 ycolletNew Issue
==

--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] Add a manifest file to the created jar

2013-06-17 Thread Matthew Woehlke

On 2013-06-17 12:25, Matthew Woehlke wrote:

On 2013-06-17 09:59, paul.chav...@fnac.net wrote:

Following this thread¹ and bug², i would like to submit a patch that
allow to specify a Manifest.txt when creating a jar.

¹ http://www.cmake.org/pipermail/cmake/2011-December/048015.html
² http://public.kitware.com/Bug/view.php?id=12886

Could you review it please ?


I am probably not the best person to have final say, but having also
worked on this module recently...


Also, patches should be posted to cmake-devel, please :-).


+if(DEFINED CMAKE_JAVA_JAR_MANIFEST)
+set(_add_jar_MANIFEST ${CMAKE_JAVA_JAR_MANIFEST})
+endif()


I would strongly suggest omitting this. The other incantations to accept
variables in lieu of named arguments are for backwards compatibility
(add_jar in CMake 2.8.10 did not have named arguments and could only be
tweaked in this manner) and are no longer the preferred method. Since
this is new functionality, there is no need to support the alternate
method of specifying a manifest file.


I pushed document-add_jar-compat-shims to stage to make this more 
explicit. Brad/Andreas/Nicolas, can you please verify that it looks 
reasonable?


Thanks,

--
Matthew

--

Powered by www.kitware.com

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

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

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

[cmake-developers] Weekly IRC Developer Chat.

2013-06-17 Thread Robert Maynard
I will be holding a developer chat in the cmake irc channel starting
at 2pm est, or 18:00 gmt.

Server: freenode
Channel: #cmake

For those without an irc client installed: http://webchat.freenode.net/
--

Powered by www.kitware.com

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

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

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


[cmake-developers] [CMake 0014226]: Fails to build, verison 2.8.10.2 was fine.

2013-06-17 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=14226 
== 
Reported By:sobukus
Assigned To:
== 
Project:CMake
Issue ID:   14226
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2013-06-17 15:01 EDT
Last Modified:  2013-06-17 15:01 EDT
== 
Summary:Fails to build, verison 2.8.10.2 was fine.
Description: 
This is a 64 bit only box with a source-based GNU/Linux distro. The build of
CMake itself fails with version 2.8.11.1, while the build with 2.8.10.2 works.

There is some confusion about 32 or 64 bit, apparently. The crucial bit from the
attached logs:

[ 31%] Building CXX object Source/CMakeFiles/CMakeLib.dir/cmCryptoHash.cxx.o
In file included from /usr/src/cmake-2.8.11.1/Source/cm_sha2.h:42:0,
 from /usr/src/cmake-2.8.11.1/Source/cmCryptoHash.cxx:15:
/usr/src/cmake-2.8.11.1/Utilities/cmIML/INT.h:829:1: error: conflicting
declaration 'int (* cmIML_INT_intptr_t__VERIFY__)[4]'
/usr/src/cmake-2.8.11.1/Utilities/cmIML/INT.h:829:1: error:
'cmIML_INT_intptr_t__VERIFY__' has a previous declaration as 'int (*
cmIML_INT_intptr_t__VERIFY__)[8]'
/usr/src/cmake-2.8.11.1/Utilities/cmIML/INT.h:832:1: error: conflicting
declaration 'int (* cmIML_INT_uintptr_t__VERIFY__)[4]'
/usr/src/cmake-2.8.11.1/Utilities/cmIML/INT.h:832:1: error:
'cmIML_INT_uintptr_t__VERIFY__' has a previous declaration as 'int (*
cmIML_INT_uintptr_t__VERIFY__)[8]'
make[2]: *** [Source/CMakeFiles/CMakeLib.dir/cmCryptoHash.cxx.o] Error 1
make[2]: *** Waiting for unfinished jobs


Steps to Reproduce: 
That's the tricky part: This seems to happen on my box only so far. Others with
the same distro reported successful builds. It can be my specific set of tools
in the chain, as the distro allows a rather free mix of versions.

But really, with the current setup, the old CMake builds fine, while the new one
fails. So at least I can reproduce it reliably.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2013-06-17 15:01 sobukusNew Issue
2013-06-17 15:01 sobukusFile Added: cmake-2.8.11.1.bz2  
 
==

--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] CMake branch, next, updated. v2.8.11.1-2643-g6a0bf5e

2013-06-17 Thread Stephen Kelly
Robert Maynard wrote:

 @@ -666,7 +666,7 @@ public:
 */
 const std::vectorstd::string GetOutputFiles() const
 { return this-OutputFiles; }
 -  void AddCMakeOutputFile(const char* file)
 +  void AddCMakeOutputFile(const std::string file)

It makes sense to split this into a separate patch.

Thanks,

Steve.

--

Powered by www.kitware.com

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

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

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


[cmake-developers] NMake Makefiles JOM issues with MinGW compiler

2013-06-17 Thread Alan W. Irwin

On 2013-06-14 16:08-0400 Bill Hoffman wrote:


Figured it out sort of...


http://public.kitware.com/pipermail/cmake-developers/2013-June/007494.html

has this link:
A non-text attachment was scrubbed...
Name: build_dir.tar.gz
Type: application/octet-stream
Size: 13997 bytes
Desc: compressed build directory generated with --debug-trycompile for the 
two-line jom/mingw test project
URL: 
http://public.kitware.com/pipermail/cmake-developers/attachments/20130610/029d16d0/attachment.obj


I was able to get your files...


Here is the problem:

Modules/Platform/Windows-GNU.cmake:64 (enable_language):
 To use the JOM generator, cmake must be run from a shell that can use the
 compiler cl from the command line.  This environment does not contain
 INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to
 work.
Call Stack (most recent call first):

Z:/home/wine/newstart/cmake-2.8.10.2-win32-x86/share/cmake-2.8/Modules/Platform/Windows-GNU-C.cmake:1 
(include)


Z:/home/wine/newstart/cmake-2.8.10.2-win32-x86/share/cmake-2.8/Modules/CMakeCInformation.cmake:56 
(include)

 CMakeLists.txt:1 (project)


CMake Error: your RC compiler: CMAKE_RC_COMPILER-NOTFOUND was not found. 
Please set CMAKE_RC_COMPILER to a valid compiler path or name.
-- Check for working C compiler: 
z:/home/wine/newstart/MinGW-4.7.2/bin/gcc.exe

CMake Warning at CMakeLists.txt:2 (PROJECT):
 To use the JOM generator, cmake must be run from a shell that can use the
 compiler cl from the command line.  This environment does not contain
 INCLUDE, LIB, or LIBPATH, and these must be set for the cl compiler to
 work.



It is trying to enable the RC compiler and it can not find one.

Try commenting that out in  Windows-GNU.cmake like this:

#enable_language(RC)

Then see if it works.


Hi Bill:

I was glad you could access the attachment from the list version. So I
am putting this discussion back on the list so you can continue to do
that.

My own gut feeling is that commenting out enable_language(RC) is
simply trying to mask symptoms of a bug caused by the NMake Makefiles
JOM generator not initializing things correctly for the MinGW suite
of compilers.  After all, generators that are compatible with the
MinGW suite of compilers execute Windows-GNU.cmake without issues.
Nevertheless, you may have had something definite in mind when
proposing this experiment so I did exactly what you suggested. The
cmake command (with enable_language(RC) commented out) was invoked
like this:

bash.exe-3.1$ cmake --debug-trycompile -GNMake Makefiles JOM \
-DCMAKE_C_COMPILER=gcc ..  cmake.out

Unlike before where that exact same command (without commenting out
enable_language(RC)) errored out, this time that command hung.
There was no cpu time being spent on this according to top (which I an
run in the background on my Linux system to see what resources Wine is
using).  But I had to use crtl-C to get the above cmake command to
exit.

Just to review, the CMakeLists.txt file consists
of the following two lines:

project(test_jom_mingw C)
cmake_minimum_required(VERSION 2.8.10.2)

I have attached a compressed tarball of the entire build tree so you
can see the exact results on my system.  However, it is quite possible
the hang on the Wine version of Windows will turn into some condition
with better diagnostics on Microsoft Windows.  Thus, could you please
run the above two-line project yourself in the manner I have described
(first without commenting out enable_language(RC) to confirm there
is also an issue on the Microsoft version of Windows) to see what
happens for the Microsoft version of Windows?

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__

build_dir_withoutRC.tar.gz
Description: build tree resulting from experiment
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] The Ninja generator errors out for any project that enables Fortran

2013-06-17 Thread Mathias Gaunard

On 14/06/2013 03:24, Bill Hoffman wrote:

On 6/13/2013 7:35 PM, Alan W. Irwin wrote:


If anyone here is game to do a quick fix for the Ninja generator so
that is supports Fortran, I would be happy to help out by testing the
fix using the build_projects project on the Linux and Wine platforms
that are accessible to me.

There is no quick fix.  The fortran depend issue is not easily solved
which is why it is not yet implemented.  It will take several weeks of
development and some possible changes to ninja to accomplish this task.
  Sadly, I have not found a funding source or developer willing to
support this effort.


Even for C/C++, it could be interesting to have an option to make Ninja 
use pre-generated dependencies from the CMake scanner instead of special 
gcc commands to automagically generate them.


The code to deal with this already exists in the Make generator.

--

Powered by www.kitware.com

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

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

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