[cmake-developers] Support for Precompiled Headers

2012-06-14 Thread Daniel Pfeifer
Hi,

In a private mailing with Dave Abrahams and Brad King I wrote a
proposal of how I imagine PCH support should be implemented. Brad
asked me to send it to this list for further discussion.
Please note that even though I use present tense in the proposal,
nothing descibed below is implemented yet.
We have a similar implementation for PCH [1], but the interface
differs to this proposal.

[1] 
https://github.com/ryppl/ryppl/blob/develop/cmake/Modules/RypplPrecompileHeader.cmake

cheers, Daniel



CMakeLists.txt changes
--
There are new target properties PRECOMPILE_HEADER and
PRECOMPILE_HEADER_config. These properties may be set to a list of
header files:

set_property(TARGET target APPEND PROPERTY PRECOMPILE_HEADER
 boost/spirit/karma.hpp
 my/precompiled/header.h
 )


changes to source files
---
None. All source files should be written as if there was no PCH
support. That means that each file should include all the headers it
requires. Nothing more, nothing less.

That especially means that source files should *NOT* include an
all.h, precompile.h, or stdafx.h file. Nothing breaks if they
do, but it may impact compile times if precompiled headers are not
supported.


file(s) to precompile
-
Special header files that contain all the system headers may be
created and added to the PRECOMPILE_HEADER property. However, the
system headers may also be added directly to PRECOMPILE_HEADER.

If custom files are created, it is important to note that a special
PCH_SUPPORTED guard is *NOT* required.


What is done behind the scenes
--
CMake creates the actual header file that is going to be precompiled
during the config step inside the current binary directory. The
complete filename encodes the target name and the configuration (eg.
${CMAKE_CURRENT_BINARY_DIR}/${target}_${config}_pch.hpp) and
contains one #include directive for each element in the
PRECOMPILE_HEADER/PRECOMPILE_HEADER_config list. If the element is
wrapped in angle brackets, it is included unmodified, otherwise the
*absolute path* is used in double quotes. The generated header file
for the above example may look like this:

/* generated by CMake 2.8.x */
#include boost/spirit/karma.hpp
#include /home/daniel/workspace/foo/my/precompiled/header.h


This header file is compiled before all object files of the target; ie
the object files depend on the compiled header.


MSVC specific
-
MSVC requires a source file to compile the header. This source file is
generated by CMake alongside the header file and may be called
target_pch.cpp, for example. It contains just one line: an #include
directive that includes the configured header file.

The precompiled header (pch_binary) is created by compiling the source
file (pch_source) with /Yc\${pch_header}\ /Fp\${pch_binary}\.

For the MSVC IDE, pch_binary might be $(IntDir)/${target}.pch.

All other source files are compiled with /Yu\${pch_header}\
/FI\${pch_header}\ /Fp\${pch_binary}\.

/Yc = create pch
/Yu = use pch
/FI = force include
/Fp = name pch binary


GCC specific

In GCC the pch_binary is created by compiling the header file directly
(no extra source file is required). The pch_binary must be
${pch_header}.pch, there is no way to change that. Here, it pays off
again that we generate the actual pch_header in the binary directory.

The compile flags to compile the header are -x c++-header and the
output file must be set with -o ${pch_binary}

All the other source files are compiled with -include ${pch_header}
(force include), it may also be a good idea to pass -Winvalid-pch.
--

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] ninja generator dashboard red

2012-06-14 Thread Bill Hoffman
Now that the ninja generator is on by default on windows, it is not 
building on the old compilers.  Looks like it is missing a std:: on a 
make_pair call.


-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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


[cmake-developers] [CMake 0013303]: Strange issues when using target_link_libraries to link stlport and boost on XCode 4

2012-06-14 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=13303 
== 
Reported By:tree
Assigned To:
== 
Project:CMake
Issue ID:   13303
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2012-06-14 11:09 EDT
Last Modified:  2012-06-14 11:09 EDT
== 
Summary:Strange issues when using target_link_libraries to
link stlport and boost on XCode 4
Description: 
I orgnize stlport libraries in two directories like:
stlport/Debug/libstlportstlg.5.2.1.dylib (represented as A)
stlport/Release/libstlport.5.2.dylib (represented as B)

and then use command
target_link_libraries(taget debug ${A})
target_link_libraries(taget optimized ${B})

After generating XCode project, I found in Building Settings/Other Linker
Flags, both the two libraries exist under both Debug and RelWithDebInfo.

In happens to boost either. But for other libraries it works as expected.

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-06-14 11:09 tree   New Issue
==

--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] ninja generator dashboard red

2012-06-14 Thread Peter Kümmel

On 14.06.2012 17:05, Bill Hoffman wrote:

Now that the ninja generator is on by default on windows, it is not
building on the old compilers.  Looks like it is missing a std:: on a
make_pair call.


I'll have a look at it. (I'm also busy fixing the broken Linux tests since my 
last commit)



-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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] Support for Precompiled Headers

2012-06-14 Thread Daniel Pfeifer
2012/6/14 David Cole david.c...@kitware.com:
 Sounds awesome to me!

 When can you submit a patch? :-)


Thanks for the motivation! While I would like to contribute a patch, I
have absolutely no idea where to start.
Should it go to cmAddExecutableCommand.cxx and
cmAddLibraryCommand.cxx? Or rather directly to the generator(s)?

Given that the required changes are probably very small (the
implementation that I linked above is less than 100 lines of CMake
code), it is maybe more effort for you to get me started than it is to
implement it... :-)

cheers, Daniel


 On Thu, Jun 14, 2012 at 4:36 AM, Daniel Pfeifer dan...@pfeifer-mail.de
 wrote:

 Hi,

 In a private mailing with Dave Abrahams and Brad King I wrote a
 proposal of how I imagine PCH support should be implemented. Brad
 asked me to send it to this list for further discussion.
 Please note that even though I use present tense in the proposal,
 nothing descibed below is implemented yet.
 We have a similar implementation for PCH [1], but the interface
 differs to this proposal.

 [1]
 https://github.com/ryppl/ryppl/blob/develop/cmake/Modules/RypplPrecompileHeader.cmake

 cheers, Daniel



 CMakeLists.txt changes
 --
 There are new target properties PRECOMPILE_HEADER and
 PRECOMPILE_HEADER_config. These properties may be set to a list of
 header files:

 set_property(TARGET target APPEND PROPERTY PRECOMPILE_HEADER
  boost/spirit/karma.hpp
  my/precompiled/header.h
  )


 changes to source files
 ---
 None. All source files should be written as if there was no PCH
 support. That means that each file should include all the headers it
 requires. Nothing more, nothing less.

 That especially means that source files should *NOT* include an
 all.h, precompile.h, or stdafx.h file. Nothing breaks if they
 do, but it may impact compile times if precompiled headers are not
 supported.


 file(s) to precompile
 -
 Special header files that contain all the system headers may be
 created and added to the PRECOMPILE_HEADER property. However, the
 system headers may also be added directly to PRECOMPILE_HEADER.

 If custom files are created, it is important to note that a special
 PCH_SUPPORTED guard is *NOT* required.


 What is done behind the scenes
 --
 CMake creates the actual header file that is going to be precompiled
 during the config step inside the current binary directory. The
 complete filename encodes the target name and the configuration (eg.
 ${CMAKE_CURRENT_BINARY_DIR}/${target}_${config}_pch.hpp) and
 contains one #include directive for each element in the
 PRECOMPILE_HEADER/PRECOMPILE_HEADER_config list. If the element is
 wrapped in angle brackets, it is included unmodified, otherwise the
 *absolute path* is used in double quotes. The generated header file
 for the above example may look like this:

 /* generated by CMake 2.8.x */
 #include boost/spirit/karma.hpp
 #include /home/daniel/workspace/foo/my/precompiled/header.h


 This header file is compiled before all object files of the target; ie
 the object files depend on the compiled header.


 MSVC specific
 -
 MSVC requires a source file to compile the header. This source file is
 generated by CMake alongside the header file and may be called
 target_pch.cpp, for example. It contains just one line: an #include
 directive that includes the configured header file.

 The precompiled header (pch_binary) is created by compiling the source
 file (pch_source) with /Yc\${pch_header}\ /Fp\${pch_binary}\.

 For the MSVC IDE, pch_binary might be $(IntDir)/${target}.pch.

 All other source files are compiled with /Yu\${pch_header}\
 /FI\${pch_header}\ /Fp\${pch_binary}\.

 /Yc = create pch
 /Yu = use pch
 /FI = force include
 /Fp = name pch binary


 GCC specific
 
 In GCC the pch_binary is created by compiling the header file directly
 (no extra source file is required). The pch_binary must be
 ${pch_header}.pch, there is no way to change that. Here, it pays off
 again that we generate the actual pch_header in the binary directory.

 The compile flags to compile the header are -x c++-header and the
 output file must be set with -o ${pch_binary}

 All the other source files are compiled with -include ${pch_header}
 (force include), it may also be a good idea to pass -Winvalid-pch.
 --

 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


--

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:

[cmake-developers] [CMake 0013304]: rpmbuild -bb cmake.spec fails on CTestTestFailedSubmint-ftp

2012-06-14 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=13304 
== 
Reported By:Shawn Adams
Assigned To:
== 
Project:CMake
Issue ID:   13304
Category:   (No Category)
Reproducibility:always
Severity:   major
Priority:   high
Status: new
== 
Date Submitted: 2012-06-14 12:59 EDT
Last Modified:  2012-06-14 12:59 EDT
== 
Summary:rpmbuild -bb cmake.spec fails on
CTestTestFailedSubmint-ftp
Description: 
rpmbuild fails to compile cmake-2.8.8. CTestTestFailedSubmit-ftp fails with the
following: 168/228 Test http://public.kitware.com/Bug/view.php?id=173:
CTestTestFailedSubmit-ftp ...***Failed  Required regular
expression not found.Regex=[(Problems when submitting via S*CP|Error message
was: ([Cc]ould *n.t resolve host|[Cc]ould *n.t connect to host|Empty reply from
server|The requested URL returned error|libcurl was built with SSL disabled.
https: not supported)|Submission method .xmlrpc. not compiled into
CTest|Submission problem|Submission successful)

Steps to Reproduce: 
rpmbuild -bb ./SPECS/cmake.spec
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-06-14 12:59 Shawn AdamsNew Issue
2012-06-14 12:59 Shawn AdamsFile Added: cmake.spec   
==

--

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] The Borland compiler dashboard errors

2012-06-14 Thread David Cole
I've got a fix locally in the ninja normal target generator:

  std::string flags = (targetType == cmTarget::EXECUTABLE
   ? vars[FLAGS]
   : vars[ARCH_FLAGS]);
  locGtor-AddArchitectureFlags(flags,
 this-GetTarget(),
 this-TargetLinkLanguage,
 this-GetConfigName());
  if (targetType == cmTarget::EXECUTABLE) {
vars[FLAGS] = flags;
  } else {
vars[ARCH_FLAGS] = flags;
  }

That should fix the Borland compilers.

OK with you if I push it on top of the stage/ninja-cldeps branch? Or do you
already have something similar planned?


Thanks,
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

Re: [cmake-developers] The Borland compiler dashboard errors

2012-06-14 Thread Peter Kümmel

On 14.06.2012 19:43, David Cole wrote:

I've got a fix locally in the ninja normal target generator:

   std::string flags = (targetType == cmTarget::EXECUTABLE
? vars[FLAGS]
: vars[ARCH_FLAGS]);
   locGtor-AddArchitectureFlags(flags,
  this-GetTarget(),
  this-TargetLinkLanguage,
  this-GetConfigName());
   if (targetType == cmTarget::EXECUTABLE) {
 vars[FLAGS] = flags;
   } else {
 vars[ARCH_FLAGS] = flags;
   }

That should fix the Borland compilers.

OK with you if I push it on top of the stage/ninja-cldeps branch? Or do you 
already have something similar planned?



No problem. I have also looked at this, but I wasn't sure about the line number.
Which branch does the build server use?



Thanks,
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers


Re: [cmake-developers] The Borland compiler dashboard errors

2012-06-14 Thread David Cole
The Continuous dashboards check 'next' -- the Nightly dashboards snap to
'nightly' which is a snapshot of 'next' created at the nightly start time
each night...

So, after a merge to 'next' on the stage, the dashboards will pick up those
changes next time they run.


On Thu, Jun 14, 2012 at 2:39 PM, Peter Kümmel syntheti...@gmx.net wrote:

 On 14.06.2012 19:43, David Cole wrote:

 I've got a fix locally in the ninja normal target generator:

   std::string flags = (targetType == cmTarget::EXECUTABLE
? vars[FLAGS]
: vars[ARCH_FLAGS]);
   locGtor-AddArchitectureFlags(**flags,
  this-GetTarget(),
  this-TargetLinkLanguage,
  this-GetConfigName());
   if (targetType == cmTarget::EXECUTABLE) {
 vars[FLAGS] = flags;
   } else {
 vars[ARCH_FLAGS] = flags;
   }

 That should fix the Borland compilers.

 OK with you if I push it on top of the stage/ninja-cldeps branch? Or do
 you already have something similar planned?


 No problem. I have also looked at this, but I wasn't sure about the line
 number.
 Which branch does the build server use?


 Thanks,
 David C.

  --

 Powered by www.kitware.com

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

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

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

--

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 Borland compiler dashboard errors

2012-06-14 Thread David Cole
OK -- I merged the change to next at the tip of the stage/ninja-cldeps
branch:


http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=555bda4e436435c37690aa5f31f4d254793d5b4e


On Thu, Jun 14, 2012 at 3:17 PM, David Cole david.c...@kitware.com wrote:

 The Continuous dashboards check 'next' -- the Nightly dashboards snap to
 'nightly' which is a snapshot of 'next' created at the nightly start time
 each night...

 So, after a merge to 'next' on the stage, the dashboards will pick up
 those changes next time they run.


 On Thu, Jun 14, 2012 at 2:39 PM, Peter Kümmel syntheti...@gmx.net wrote:

 On 14.06.2012 19:43, David Cole wrote:

 I've got a fix locally in the ninja normal target generator:

   std::string flags = (targetType == cmTarget::EXECUTABLE
? vars[FLAGS]
: vars[ARCH_FLAGS]);
   locGtor-AddArchitectureFlags(**flags,
  this-GetTarget(),
  this-TargetLinkLanguage,
  this-GetConfigName());
   if (targetType == cmTarget::EXECUTABLE) {
 vars[FLAGS] = flags;
   } else {
 vars[ARCH_FLAGS] = flags;
   }

 That should fix the Borland compilers.

 OK with you if I push it on top of the stage/ninja-cldeps branch? Or do
 you already have something similar planned?


 No problem. I have also looked at this, but I wasn't sure about the line
 number.
 Which branch does the build server use?


 Thanks,
 David C.

  --

 Powered by www.kitware.com

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

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

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



--

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 0013306]: findglut bug

2012-06-14 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=13306 
== 
Reported By:Jona
Assigned To:
== 
Project:CMake
Issue ID:   13306
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2012-06-14 16:45 EDT
Last Modified:  2012-06-14 16:45 EDT
== 
Summary:findglut bug
Description: 
I have installed freeglut on my system, but FindGlut.cmake is unable to find it.
I have an enviroment variable called GLUT_ROOT_PATH but it is not used by the
skript.

I rewrote the script and now it works for me:

IF (WIN32)
  FIND_PATH( GLUT_INCLUDE_DIR NAMES GL/glut.h 
PATHS  ENV GLUT_ROOT_PATH
PATH_SUFFIXES include
)
  FIND_LIBRARY( GLUT_glut_LIBRARY NAMES glut glut32 freeglut
PATHS ENV OPENGL_LIBRARY_DIR GLUT_ROOT_PATH
PATH_SUFFIXES Release lib
)
ELSE (WIN32)

The old version was:
IF (WIN32)
  FIND_PATH( GLUT_INCLUDE_DIR NAMES GL/glut.h 
PATHS  ${GLUT_ROOT_PATH}/include )
  FIND_LIBRARY( GLUT_glut_LIBRARY NAMES glut glut32 freeglut
PATHS
${OPENGL_LIBRARY_DIR}
${GLUT_ROOT_PATH}/Release
)
ELSE (WIN32)

(as I can see, it uses the cmake variable GLUT_ROOT_PATH instead of the
enviromentvariable and doenst look inside /lib for the library.


== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-06-14 16:45 Jona   New Issue
==

--

Powered by www.kitware.com

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

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

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


[cmake-developers] Recommended usage of OBJECT_DEPENDS

2012-06-14 Thread Alexander Neundorf
Hi,

we hit an issue in KDE related to the usage (or not-usage) of the 
OBJECT_DEPENDS source file property.

In KDEs FindQt4.cmake the macro 
qt4_generate_moc(inCppFile outMocFile)
uses the OBJECT_DEPENDS property to enforce that the moc file is generated 
before the cpp file is built.
This seems to work reliably, at least I haven't heard of any problems with 
this since years.

Now the same macro in cmake does not set the OBJECT_DEPENDS property.

Should it ?
Is enforcing such a dependency a valid use case for OBJECT_DEPENDS ?


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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0013307]: CPack Generators producing a single package only

2012-06-14 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
http://public.kitware.com/Bug/view.php?id=13307 
== 
Reported By:Javier
Assigned To:
== 
Project:CMake
Issue ID:   13307
Category:   CPack
Reproducibility:always
Severity:   major
Priority:   high
Status: new
== 
Date Submitted: 2012-06-14 17:36 EDT
Last Modified:  2012-06-14 17:36 EDT
== 
Summary:CPack Generators producing a single package only
Description: 
When I try the component example as described in issue
http://public.kitware.com/Bug/view.php?id=10736, sample downloaded from the
links there, ZIP, TGZ, TG, STGZ generators generate a monolithic generator only.


I downloaded CMake 2.8.3, and used the exact same example on the same
environment, and the separate packages are generated correctly.

Steps to Reproduce: 
1) Download component example file:
http://www.vtk.org/Wiki/File:ComponentExampleStart.zip

2) Run CMake with NMake Makefiles Generator. Running cpack -G ZIP will produce a
single .zip file. Expected one per component. 

Repeat the above steps with CMake 2.8.3, and the result is several .zip files as
expected.

Additional Information: 
- Used CMake 2.8.8
- NMake Generator (Using Visual Studio 2008)
- Didn't test this on Linux or OSX.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2012-06-14 17:36 Javier New Issue
==

--

Powered by www.kitware.com

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

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

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


[cmake-developers] cmake -E vs_link with response files

2012-06-14 Thread Peter Kümmel

I found a new problem were I could not
find a good solution:

cmd.exe /c $PRE_LINK
  cmake.exe -E vs_link_dll $in
  $POST_LINK

Assume $in is to big for the command line,
what could be done then. First I thought
$PRE_LINK and $POST_LINK are then empty
and could be dropped, but this is wrong.

Is there something like response files for
linking via vc_link already implemented?

Peter
--

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 -E vs_link with response files

2012-06-14 Thread Peter Kümmel

On 15.06.2012 00:33, Peter Kümmel wrote:

I found a new problem were I could not
find a good solution:

cmd.exe /c $PRE_LINK
   cmake.exe -E vs_link_dll $in
   $POST_LINK

Assume $in is to big for the command line,
what could be done then. First I thought
$PRE_LINK and $POST_LINK are then empty
and could be dropped, but this is wrong.

Is there something like response files for
linking via vc_link already implemented?



This was a false alarm. But now I have to revert a bit.

Peter
--

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