On 2014-03-27 09:35, [email protected] wrote:
Send CMake mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.cmake.org/mailman/listinfo/cmake
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of CMake digest..."
Today's Topics:
1. [ANNOUNCE] CMake 3.0-rc3 now ready for testing! (Robert Maynard)
2. improve cross compilation (Wim Van Loocke)
3. Re: CPack error in visual studio 2010 (Lloyd)
4. custom nsis template- "Install targets" not working (Lloyd)
5. Re: custom nsis template- "Install targets" not working
(Eric Noulard)
6. Re: custom nsis template- "Install targets" not working (Lloyd)
----------------------------------------------------------------------
Message: 1
Date: Wed, 26 Mar 2014 13:22:33 -0400
From: Robert Maynard <[email protected]>
To: CMake Developers <[email protected]>, CMake MailingList
<[email protected]>, [email protected]
Subject: [CMake] [ANNOUNCE] CMake 3.0-rc3 now ready for testing!
Message-ID:
<CAFzjYVqxHwY5e9Cr7cW21_B2GR93=czhynb0eowm6+y45gy...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I am proud to announce the CMake 3.0 third release candidate.
Sources and binaries are available at:
http://www.cmake.org/files/v3.0/?C=M;O=D
Documentation is available at:
http://www.cmake.org/cmake/help/v3.0
Release notes appear below and are also published at
http://www.cmake.org/cmake/help/v3.0/release/3.0.0.html
Some of the more significant features of CMake 3.0 are:
* Compatibility options supporting code written for CMake versions
prior to 2.4 have been removed.
* The CMake language has been extended with *Bracket Argument* and
*Bracket Comment* syntax inspired by Lua long brackets.
* The CMake documentation has been converted to reStructuredText and
uses Sphix generation.
* Generators for Visual Studio 10 (2010) and later were renamed to
include the product year like generators for older VS versions:
* "Visual Studio 10" -> "Visual Studio 10 2010"
* "Visual Studio 11" -> "Visual Studio 11 2012"
* "Visual Studio 12" -> "Visual Studio 12 2013"
This clarifies which generator goes with each Visual Studio version.
The old names are recognized for compatibility.
* A new "CodeLite" extra generator is available for use with the
Makefile or Ninja generators.
* A new "Kate" extra generator is available for use with the
Makefile or Ninja generators.
* The "add_library()" command learned a new "INTERFACE" library
type. Interface libraries have no build rules but may have
properties defining "usage requirements" and may be installed,
exported, and imported. This is useful to create header-only
libraries that have concrete link dependencies on other libraries.
* The "export()" command learned a new "EXPORT" mode that retrieves
the list of targets to export from an export set configured by the
"install(TARGETS)" command "EXPORT" option. This makes it easy to
export from the build tree the same targets that are exported from
the install tree.
* The "project()" command learned to set some version variables to
values specified by the new "VERSION" option or to empty strings.
See policy "CMP0048".
* Several long-outdated commands that should no longer be called
have been disallowed in new code by policies:
* Policy "CMP0029" disallows "subdir_depends()"
* Policy "CMP0030" disallows "use_mangled_mesa()"
* Policy "CMP0031" disallows "load_command()"
* Policy "CMP0032" disallows "output_required_files()"
* Policy "CMP0033" disallows "export_library_dependencies()"
* Policy "CMP0034" disallows "utility_source()"
* Policy "CMP0035" disallows "variable_requires()"
* Policy "CMP0036" disallows "build_name()"
-------------------------------------------------------------------
Changes made since CMake 3.0.0-rc1:
Aur?lien G?teau (1):
find_dependency: Give more helpful message if VERSION is empty
Bas Couwenberg (1):
FindRuby: Add support for Ruby 2.0 and 2.1
Brad King (12):
Help: Add FindRuby-2 topic release notes
Help: Consolidate FindRuby-2 release notes for 3.0.0
Help: Mention in find_package that cmake-gui step is Windows-only
(#14781)
cmake: Fix --check-build-system argument count check (#14784)
Record more policies on targets when created
Tests: Simplify and document policy scopes in RunCMake.CMP* tests
Help: Document variables CMAKE_APPBUNDLE_PATH and CMAKE_FRAMEWORK_PATH
CMakeDetermine*Compiler: Factor out search for compiler in PATH
Xcode: Convert forced CMAKE_<LANG>_COMPILER to full path if possible
CMake*CompilerId: Fix patch level for Intel >= 14.0 (#14806)
Matt McCormick (1):
FindPython{Interp,Libs}: Search for Python 3.4.
Stephen Kelly (11):
add_definitions: Don't document genex support.
CMP0043: Document old and new interfaces for setting directory property.
find_dependency: Don't propagate EXACT argument.
Qt4: Use correct qdbus executable in macro.
QtAutogen: Fix AUTOGEN depends on custom command output with VS.
find_dependency: Make sure invalid EXACT use can be reported.
cmTarget: Don't create duplicate backtraces in CMP0046 warning
QtDialog: Avoid linking to Qt4 WinMain when using Qt 5.
cmTarget: Restore <CONFIG>_LOCATION to CMP0026 OLD behavior (#14808)
QtDialog: Fix Qt 5 build on non-Windows.
Disallow INTERFACE libraries with add_custom_command(TARGET).
------------------------------
Message: 2
Date: Wed, 26 Mar 2014 20:40:15 +0100
From: Wim Van Loocke <[email protected]>
To: [email protected]
Subject: [CMake] improve cross compilation
Message-ID:
<CAG+bEaOkEkXg+zOK13gkUB1XgF_FH_8=pthyd_8z_9+6rta...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi All,
The way the cross-compiling is described with a separated file with the
cross-compilation is working
set(COMPILER_PATH /opt/Xilinx/SDK/2013.4/gnu/arm/lin/bin/)
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_VERSION 1)
set(CMAKE_SYSTEM_PROCESSOR arm)
# specify the cross compiler
set (CMAKE_C_COMPILER ${COMPILER_PATH}arm-xilinx-linux-gnueabi-gcc )
set (CMAKE_CXX_COMPILER ${COMPILER_PATH}arm-xilinx-linux-gnueabi-g++ )
I have looked into the code and see that in CMakeSystem.cmake the toolchain
parameters are added, and this is kept as the build system. This is done
even before parsing much of the CMakeLists.txt file.
As such only via the -DCMAKE_TOOLCHAIN_FILE this file is updated.
Looking to a real environment, the same toolchain can be installed on
different places.
To make cmake have advantage, for every installation ( where ever a user
may choose to install ) i have to create personalized file, so a lot of
almost same files for one cross compile tool has to be created.
I think it has a big advantage if the COMPILER_PATH CROSS_COMPILER values
could be set when invoking cmake and move the cross-compile stuff into the
CMakeFiles.
I have no insight in the design of cmake, just in the code , if it is
available i'm willing to see how this can be added to cmake.
I hope cmake team is willing to have look to this. and give some feedback.
Kind regards,
Wim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.cmake.org/pipermail/cmake/attachments/20140326/0c162d6c/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 27 Mar 2014 11:22:41 +0530
From: Lloyd <[email protected]>
To: CMake ML <[email protected]>
Subject: Re: [CMake] CPack error in visual studio 2010
Message-ID:
<CAA10ZTpSTDtmpnjg2wxXLc6WGqpKyxCC-yXbfye1sp=83m5...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
The problem disappeared now. I suspect some application (may be the
antivirus or a virus) was keeping that file
("C:/Users/user1/Desktop/xyz/abc-1.0.0-win32.exe")
open.
On Tue, Mar 25, 2014 at 3:33 PM, Lloyd <[email protected]> wrote:
Hi,
I am using CPack (CMake) with Visual Studio 2010. When I "build" Package,
my NSIS based installer is getting created in the
"_CPack_Packages\win32\NSIS" directory of the build directory. But the
build process in Visual Studio throws an error like the following:
Error 32 error : Problem copying the package:
C:/Users/user1/Desktop/xyz/_CPack_Packages/win32/NSIS/abc-1.0.0-win32.exe
to C:/Users/user1/Desktop/xyz/abc-1.0.0-win32.exe
What could be the reason for a "Problem copying the package" error. As
the installer creation is successful it is not generating "NSISoutput.log"
file.
Thanks,
Lloyd
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.cmake.org/pipermail/cmake/attachments/20140327/cd16afc3/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 27 Mar 2014 11:38:33 +0530
From: Lloyd <[email protected]>
To: CMake ML <[email protected]>
Subject: [CMake] custom nsis template- "Install targets" not working
Message-ID:
<CAA10ZTp=aiGM+ydWuvRc-98O=bg2wynsftx_hrfawu7y1+5...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
My CMake file contains the install comands like this
install(TARGETS MyExe RUNTIME DESTINATION .)
When I use the standard NSIS template, the installer is created with
"MyExe". But our project needs a custom NSIS template so I have written
one, and it is generating an installer *without* MyExe.
So I made a comparison between my nsis template and the standard one.
The one big difference I found is the presence of
@CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS@
@CPACK_NSIS_FULL_INSTALL@
after the SetOutPath "$INSTDIR" command. These above two variables seems to
be undocumented.
When the standard nsis template is processed, these lines are changed to
File /r "${INST_DIR}\*.*"
I am struck at this point, how can I make my install targets command work?
Any hint or documentation would be greatly appreciated.
Thanks,
Lloyd
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.cmake.org/pipermail/cmake/attachments/20140327/731d2816/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 27 Mar 2014 08:02:39 +0100
From: Eric Noulard <[email protected]>
To: Lloyd <[email protected]>
Cc: CMake ML <[email protected]>
Subject: Re: [CMake] custom nsis template- "Install targets" not
working
Message-ID:
<capasglo0zr+tkvotc05wy-1bt+wy2irtwpk7ake8ud5vcs7...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2014-03-27 7:08 GMT+01:00 Lloyd <[email protected]>:
Hi,
My CMake file contains the install comands like this
install(TARGETS MyExe RUNTIME DESTINATION .)
When I use the standard NSIS template, the installer is created with
"MyExe". But our project needs a custom NSIS template so I have written one,
and it is generating an installer *without* MyExe.
So I made a comparison between my nsis template and the standard one.
The one big difference I found is the presence of
@CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS@
@CPACK_NSIS_FULL_INSTALL@
after the SetOutPath "$INSTDIR" command. These above two variables seems to
be undocumented.
>From the source code one can see that
CPACK_NSIS_EXTRA_PREINSTALL_COMMANDS is empty unless the user provide
some value for it.
CPACK_NSIS_FULL_INSTALL is populated with "File /r
\"${INST_DIR}\\*.*\" unless the
user provide another value.
When the standard nsis template is processed, these lines are changed to
File /r "${INST_DIR}\*.*"
which corresponds to the source code default behavior.
I am struck at this point, how can I make my install targets command work?
Any hint or documentation would be greatly appreciated.
I am no NSIS expert so I can't imagine why 'File /r "${INST_DIR}\*.*"'
could possibly do ???
So I guess that if your template does not contain such command you
either need it
(and should use CPACK_NSIS_FULL_INSTALL in your template) or replace
it with something more appropriate to you case.
Now on the semantic,
CPACK_NSIS_FULL_INSTALL probably means "full install of all components"
you will find other CPACK_NSIS_*_COMPONENTS* var
CPACK_NSIS_INSTALLER_MUI_COMPONENTS_DESC
CPACK_NSIS_PAGE_COMPONENTS
CPACK_NSIS_COMPONENT_SECTIONS
CPACK_NSIS_COMPONENT_SECTION_LIST
...
See http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack
for some explanation about component vs full/monolithic install with CPack.
Hi All,
i had a further look into cross-compiling.
When i create 1 project and put the cross-compiling settings in the
CMakeLists.txt file the target is cross-compiling. When i add a
subdirectory it starts complaining, as the c++ compiler is no longer
correctly set( apparently it is only set for the localgenerator for the
toplevel project/target ).
If i compare it with CMAKE_BUILD_TYPE, if set in the top level project,
it is also set for the sublevel projects, so it is rippling through the
subprojects.
Can anyone explain we why there is a different behaviour ? ( I could not
found it back in the Mastering CMake book neither ). ?!
I don't see why it should not be valid for subprojects.
I also want to deliver a software the user can build from command line
as well as from whithin IDE ( i use QtCreator ) in "the same way" . If
everything can be put into the CMakeLists.txt, that would help.
Thanks,
Wim
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
