[CMake] CMake Digest, Vol 119, Issue 41
wim
wimvanloocke at gmail.com
Tue Apr 1 09:03:25 EDT 2014
On 2014-03-27 09:35, cmake-request at cmake.org wrote:
> Send CMake mailing list submissions to
> cmake at cmake.org
>
> 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
> cmake-request at cmake.org
>
> You can reach the person managing the list at
> cmake-owner at cmake.org
>
> 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 <robert.maynard at kitware.com>
> To: CMake Developers <cmake-developers at cmake.org>, CMake MailingList
> <cmake at cmake.org>, kde-devel at kde.org
> Subject: [CMake] [ANNOUNCE] CMake 3.0-rc3 now ready for testing!
> Message-ID:
> <CAFzjYVqxHwY5e9Cr7cW21_B2GR93=CzhYnB0EOwM6+y45GyDZQ at 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 <wimvanloocke at gmail.com>
> To: cmake at cmake.org
> Subject: [CMake] improve cross compilation
> Message-ID:
> <CAG+bEaOkEkXg+zOK13gkUB1XgF_FH_8=pthYd_8z_9+6RTAoTQ at 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 <lloydkl.tech at gmail.com>
> To: CMake ML <cmake at cmake.org>
> Subject: Re: [CMake] CPack error in visual studio 2010
> Message-ID:
> <CAA10ZTpSTDtmpnjg2wxXLc6WGqpKyxCC-yXbfye1sp=83m5iGQ at 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 <lloydkl.tech at gmail.com> 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 <lloydkl.tech at gmail.com>
> To: CMake ML <cmake at cmake.org>
> Subject: [CMake] custom nsis template- "Install targets" not working
> Message-ID:
> <CAA10ZTp=aiGM+ydWuvRc-98O=bG2WYNsftx_HRFAwu7y1+5KiQ at 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 <eric.noulard at gmail.com>
> To: Lloyd <lloydkl.tech at gmail.com>
> Cc: CMake ML <cmake at cmake.org>
> Subject: Re: [CMake] custom nsis template- "Install targets" not
> working
> Message-ID:
> <CAPASGLo0zR+tkvoTc05Wy-1bT+WY2irTwpK7aKe8ud5vCs7_JQ at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 2014-03-27 7:08 GMT+01:00 Lloyd <lloydkl.tech at gmail.com>:
>> 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
More information about the CMake
mailing list