[Cmake-commits] CMake branch, next, updated. v3.3.0-1904-g1e0d21e

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 1e0d21e449ca1baed38683acb052f46e26526d73 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.0-1906-gaac63e3

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via aac63e39213c28b139ce4793684e199190aa659a (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.0-1908-ge63dcb4

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via e63dcb41ddd21175acbd57588f5df92397c46d09 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.0-1945-gcb91af0

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via cb91af0e2e44760abbe34853a3b89a5f300e15ad (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.0-1982-g3350a96

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 3350a96d57f0694be3cb0a305aad9ae82b75e790 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.0-1985-gabfa794

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via abfa7948673c618437c0b9cdaf7588591f334cf2 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.0-694-g863b0a8

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 863b0a8ee9eb7a19226a37edd1d8a398462379a1 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.0-1987-g1ee82fb

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 1ee82fb5e1e83c43d30cc65c857dcdf81aa313d7 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.0-692-gfccb3e2

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via fccb3e2dae4993650a980799e571bf6ae6e304e6 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.0-1990-g31677be

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 31677be7228d3890ec7d77757a55dbf70db76ad6 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.0-1992-g662af68

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 662af68dd367056396d8c48f9854137ff05f45ba (commit) via

[CMake] NSIS Installer: Changing shortcuts 'Start in'

Hi community, we are using NSIS (CPack) for our Windows installers. Our current setup looks like this: ;Create shortcuts CreateDirectory $SMPROGRAMS\$STARTMENU_FOLDER @CPACK_NSIS_CREATE_ICONS@ @CPACK_NSIS_CREATE_ICONS_EXTRA@ CreateShortCut $SMPROGRAMS\$STARTMENU_FOLDER\Uninstall.lnk

Re: [CMake] on cmake supporting one arch per project (from CMake IR)

Since CMake is the one generating the project files, it is obvious that it should be the one that is updated to add this support. The current lack of support is not due to any kind of limitation in any of the IDEs, it is purely a limitation of the tool that is generating the project files that

[CMake] Managed C++ / C# Projects: Location of assembly DLL

I am including external MS projects via CMake for my C# projects. The Managed C++ projects I generate via CMake directly. However, sharing assembly references between the two is difficult. Sometimes I need my imported C# projects to know where to find the managed C++ DLL assembly it built. This

Re: [CMake] on cmake supporting one arch per project (from CMake IR)

When I had tried it previously, It was too out of date, I will take a look. Im still hoping CMake integrates it in. Scott -Original Message- From: Greg Marr [mailto:greg.m...@autodesk.com] Sent: Wednesday, August 5, 2015 11:42 AM To: Raymond Wan; Scott Aron Bloom Cc: cmake@cmake.org

[CMake] passing a list of files from c source code to cmake

I know it's possible to send variables into your c source code from the cmake tutorials where you set the version. let's say in your c source code you access some resource files that are located in your source tree under a resources folder. I can put those in some type of array in my c source

Re: [CMake] passing a list of files from c source code to cmake

On Wed, Aug 5, 2015 at 3:17 PM, Owen Alanzo Hogarth gurenc...@gmail.com wrote: I can put those in some type of array in my c source code. Now is it possible to send that list back to cmake at build time so that it can copy those files to the binary tree on each build? You can write a script

Re: [CMake] passing a list of files from c source code to cmake

I don't think it needs to be a custom command, you just do it inline. See e.g. FILE(STRINGS, ...) http://www.cmake.org/cmake/help/v3.0/command/file.html or FILE(READ, ...) http://www.cmake.org/pipermail/cmake/2007-May/014222.html There are several gotchas related to quoting. Ping the list if you

Re: [cmake-developers] Supporting monolithic and efficient CMake + Ninja builds for LLVM developers

Chris Bieneman wrote: (resending now that I’ve subscribed to cmake-developers) Hello CMake-Developers, I’m a contributor to the LLVM project working on improving our CMake-based build process, and I had a request I wanted to discuss with your community. This is related to a feature

[Cmake-commits] CMake branch, master, updated. v3.3.0-695-g42526ef

20150805) +set(CMake_VERSION_PATCH 20150806) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake

Re: [CMake] passing a list of files from c source code to cmake

a combination of the above.. somefile.h file1, file2, file3 somefile.c ... const char *files[] = { #include somefile.h }; would be easiest for cmake to parse the .h... I would think... otherwise no; might be easier to maintain the list in the cmake and stuff it into the C using

[cmake-developers] [CMake 0015682]: [biicode] Ninja generator uses relative paths in target description when including parent directory

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15682 == Reported By:Sam Spilsbury Assigned To:

[cmake-developers] [CMake 0015683]: Extend --trace to --coverage mode for detection of dead cmake code

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15683 == Reported By:j.kreuzberger Assigned To:

[cmake-developers] [PATCH] Add --no-install-deps to bootstrapping procedure

MSYS2 uses Pacman to manage package dependencies so without this patch, our mingw-w64-cmake-git package ends up bundling all the DLLs it depends on which causes conflicts with the packages those DLLs really belong to. Please review. -- Best regards, Ray Donnelly.

Re: [cmake-developers] Java support

Hi, For point 1. I completely forgot to test with VS generators… I will work on that ASAP. For point 2., The best approach is to install 32 and 64bit versions of Java SDK (Windows versions, not some cygwin or MSYS versions) and ensure JAVA_HOME is NOT set in the environment nor referenced in

Re: [cmake-developers] Java support

Hi, Again, a new version for patch 4. I hope I didn’t miss anything this time. :) To handle VS generators, I am relying on generator-expressions supported by add_test function. Marc On 04/08/15 17:42, Brad King brad.k...@kitware.com wrote: On 08/04/2015 04:45 AM, CHEVRIER, Marc wrote:

[cmake-developers] [CMake 0015684]: CMAKE_Fortran_COMPILER_VERSION becomes unset after second configuring

The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15684 == Reported By:Raul Laasner Assigned To:

[cmake-developers] The naming convention SHARED and STATIC

Encourage best practices. For example, I want to export one and the same library in one package in debug and release configurations. What do you name CMake targets and how to name files? -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] The naming convention SHARED and STATIC

Addition: SHARED and STATIC too (mylibstatic and mylibshared?)16:39, 5 августа 2015 г., Konstantin Podsvirov konstan...@podsvirov.pro:Encourage best practices. For example, I want to export one and the same library in one package in debug and release configurations. What do you name CMake targets

[cmake-developers] [PATCH] Add --no-install-deps to bootstrapping procedure

I left some debug stuff in the last version. Here it is without that; apologies. MSYS2 uses Pacman to manage package dependencies so without this patch, our mingw-w64-cmake-git package ends up bundling all the DLLs it depends on which causes conflicts with the packages those DLLs really belong

[cmake-developers] Silencing warning about environment when using NMake / JOM

Hi, While using the NMake and JOM generators in CMake, I have come across this warning: To use the [NMake | 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

Re: [cmake-developers] Java support

On 08/05/2015 03:15 AM, CHEVRIER, Marc wrote: For point 2., The best approach is to install 32 and 64bit versions of Java SDK (Windows versions, not some cygwin or MSYS versions) and ensure JAVA_HOME is NOT set in the environment nor referenced in the PATH. In this case, CMake FindJava.cmake

Re: [cmake-developers] Silencing warning about environment when using NMake / JOM

On 08/05/2015 11:17 AM, James Johnston wrote: To use the [NMake | 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. OK,

[cmake-developers] [CMake 0015685]: When packaging cmake-gui Qt dlls are resolved from the PATH and not from the Qt installation directory used to build CMake

The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15685 == Reported By:Mourad Assigned To:

Re: [cmake-developers] [PATCH] Add --no-install-deps to bootstrapping procedure

On 08/05/2015 11:16 AM, Ray Donnelly wrote: MSYS2 uses Pacman to manage package dependencies so without this patch, our mingw-w64-cmake-git package ends up bundling all the DLLs it depends on which causes conflicts with the packages those DLLs really belong to. I don't think we should require

Re: [cmake-developers] [PATCH] Add --no-install-deps to bootstrapping procedure

On Wed, Aug 5, 2015 at 6:34 PM, Brad King brad.k...@kitware.com wrote: On 08/05/2015 11:16 AM, Ray Donnelly wrote: MSYS2 uses Pacman to manage package dependencies so without this patch, our mingw-w64-cmake-git package ends up bundling all the DLLs it depends on which causes conflicts with the

[cmake-developers] Supporting monolithic and efficient CMake + Ninja builds for LLVM developers

(resending now that I’ve subscribed to cmake-developers) Hello CMake-Developers, I’m a contributor to the LLVM project working on improving our CMake-based build process, and I had a request I wanted to discuss with your community. This is related to a feature request I filed

[cmake-developers] [PATCH] nmake/jom: Only warn about bad VS environment if compiler not found

Hi, Attached is a patch that changes the warning of nmake/jom generators when VCVarsAll.bat hasn't been run: nmake and jom generators no longer warn about missing INCLUDE/LIB environment variables unless the C/CXX compiler cannot be found. This is useful if the user does not want to