Re: [cmake-developers] How to set startup project in Visual Studio

One might be able to use FILE() to generate a .vcxproj.user if( NOT EXISTS ) This is a version from 2012 project. ALL_BUILD.vcxproj.user (it's the default project. so it's the one i usually set, unless something clever along these lines happened ) 

Re: [cmake-developers] speed up package with mingw on Windows host

I’m looking at platforms which need rpath rewrite. Maybe I’m wrong but I imagine that the patch will be more complicated (and my knowledge of cpack architecture is limited). Why not activate this optimisation only for mingw32, cause the main problem is cpack with mingw32 is unusable for the

Re: [cmake-developers] speed up package with mingw on Windows host

On Mon, Jun 20, 2016 at 23:05:11 +0200, laurent wrote: > I mean dependencies will be marked as *analysed* at global scope. > > Is cpack able to pack 2 binaries at the same time ? Concurrently, no. In a single invokation, yes (though it is still just one package). > Maybe i could suffix

Re: [cmake-developers] How to set startup project in Visual Studio

J Decker wrote: > The setting is in a different file that's .vcproj.user (or .user.vcproj) And there is not one of these for each project() command? It seems to me that this should either be a GLOBAL property, or the documentation which directory to set the DIRECTORY property on. I have no

Re: [cmake-developers] CMake 32 and 64 bit packages on Windows

Brad King wrote: > MSI > takes care of reversing effects of the removed installation, so that > may have removed it from your PATH. Hmm, the steps I took were: * Uninstall my pre-existing CMake 3.1 installation * Install the CMake 3.5 32 bit package ** At this point everything worked on the

Re: [cmake-developers] speed up package with mingw on Windows host

I prefer : Laurent Tarrisse Could you make the correction by yourself or do I need to re-send my patch with correct full name ? I wonder if my next patch will not break packing with multi package ? I mean dependencies will be marked as *analysed* at global scope. Is cpack able to pack 2

Re: [cmake-developers] Dogfooding: clang-tidy, include-what-you-use, link-what-you-use

On 06/13/2016 10:16 AM, Brad King wrote: > On 06/12/2016 05:47 PM, Daniel Pfeifer wrote: >> I have set up a dashboard build where all three mechanisms are enabled: Thanks. It looks like you have a Continuous build for this. That will be nice in the future but for now it is not useful until the

Re: [cmake-developers] proposal of fix for FindLua

On 06/20/2016 02:02 PM, ivan Ivanov wrote: > Fixed, please review it again Thanks, applied: FindLua: Prefix private APIs with `_lua_` https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=92c67b9f FindLua: Factor out a helper function for version extraction

Re: [cmake-developers] speed up package with mingw on Windows host

On 06/20/2016 02:49 PM, laurent wrote: > Let’s make a demonstration by example : Thanks. > Attached a git patch against current cmake master branch. Thanks. Actually I was saying that we would like to record a Full Name as your authorship. Are you: Tarrisse Laurent TARRISSE Laurent

Re: [cmake-developers] speed up package with mingw on Windows host

Let’s make a demonstration by example : // With grep $ objdump -p /c/msys32/mingw32.exe | grep "^[[:blank:]]*DLL Name: " DLL Name: KERNEL32.dll DLL Name: msvcrt.dll DLL Name: USER32.dll // With findstr $ objdump -p /c/msys32/mingw32.exe | findstr "^[[:blank:]]*DLL Name: "

Re: [cmake-developers] proposal of fix for FindLua

Fixed, please review it again (patches are attached to #15756 ) . Erase variable from cache is necessary, I think (see comment at gitlab). Ignoring of LUA_INCLUDE_DIR was my fault, fixed. For now I use this variable as a recommendation, i.e. if

Re: [cmake-developers] speed up package with mingw on Windows host

On 06/18/2016 12:10 PM, laurent wrote: > I would like to share my experience about speed up package with > BundleUtilities > on Windows host using mingw32 env. Thanks. Please provide a Full Name format name for the commit authorship record. > -find_program(gp_grep_cmd

Re: [cmake-developers] [PATCH] add debug glew to FindGLEW

Brad, Here is the patch fixed. Thanks, 2016-06-20 16:17 GMT+02:00 Brad King : > On 06/20/2016 07:55 AM, Farbos a wrote: >> I added the Glew debug library to the FindGLEW.cmake, here is the patch. > > Good start. Here are some comments: > > * For compatibility with

Re: [cmake-developers] Patch: Add ability to override the default Visual Studio tool

On 06/17/2016 05:42 PM, Gilles Khouzam wrote: > This patch is to add the ability to override the default tool > assigned by the Visual Studio generator based on the extension Thanks, applied: VS: Add a VS_TOOL_OVERRIDE source file property

Re: [cmake-developers] Patch: Add the ability to specify SDK_REFERENCES for Visual Studio

On 06/17/2016 05:34 PM, Gilles Khouzam wrote: > This patch is to add the ability with Visual Studio generators > to add references to SDKs. Thanks, applied: VS: Add VS_SDK_REFERENCES target property to reference external SDKs https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ccc6270d -Brad

Re: [cmake-developers] CMake 32 and 64 bit packages on Windows

On 06/18/2016 08:12 AM, Stephen Kelly wrote: > I tried the CMake 3.6 RC on Windows yesterday. I initially downloaded the 64 > bit version, and the installer uninstalled my CMake 3.5 (32 bit). This is because the MSI package records only a single package name for all CMake versions. Each

Re: [cmake-developers] [PATCH] add debug glew to FindGLEW

On 06/20/2016 07:55 AM, Farbos a wrote: > I added the Glew debug library to the FindGLEW.cmake, here is the patch. Good start. Here are some comments: * For compatibility with scripts that set GLEW_LIBRARY we need to honor the old name if it is set. See FindZLIB for an example. (Near the

Re: [cmake-developers] [Patch] Two trivial patches fixing type in CPack/DEB testcase

On 06/19/2016 04:42 PM, Domen Vrankar wrote: > Applied to next with extension of first patch to newer tests: > https://cmake.org/gitweb?p=cmake.git;a=commit;h=b661d4a > > Brad could this topic be merged to 3.6 since it is a test fix? I rebased the topic: CPack/Deb: Fix tests for

Re: [cmake-developers] Imported Locations in FindBoost.cmake

Hi Folks, For reference, there is an issue tracker entry for this problem: https://gitlab.kitware.com/cmake/cmake/issues/16091 Similar alternatives have been discussed there. On 06/20/2016 01:32 AM, Andreas Weis wrote: > On 6/19/2016 9:17 PM, Mike Gelfand wrote: >> The suggested way to deal

Re: [cmake-developers] Fwd: Question about CHECK_C_COMPILER_FLAG

On 06/20/2016 07:23 AM, Sergei Nikulov wrote: > Documentation will tell that "the compiler does not give an error > message when it encounters the flag". > Unfortunately, it not only compiles but try to link executable. > > If linker fails, due missed libraries it also does not produce > positive

[cmake-developers] [PATCH] add debug glew to FindGLEW

Hi, I added the Glew debug library to the FindGLEW.cmake, here is the patch. Tell me if everything looks good and if I can do a pull request. Thanks, -- Arnaud FARBOS 0001-add-debug-glew-to-FindGLEW.patch Description: Binary data -- Powered by www.kitware.com Please keep messages on-topic

[cmake-developers] Fwd: Question about CHECK_C_COMPILER_FLAG

Hi All, I have a question about CHECK_C_COMPILER_FLAG behaviour. Documentation will tell that "the compiler does not give an error message when it encounters the flag". Unfortunately, it not only compiles but try to link executable. If linker fails, due missed libraries it also does not produce