Re: [CMake] Determining a library name at configure time

Anyone? Thanks, B. On 09/18/2015 11:42 AM, Bill Newcomb wrote: Suppose I add a library in my project: add_library(foo STATIC foo.c bar.c) Is there a way I can get the name of the generated library file at configure time? LIBRARY_OUTPUT_NAME and OUTPUT_NAME for the target do not seem to be

Re: [cmake-developers] Generator expressions for install destination

Brad King wrote: > On 09/22/2015 09:58 AM, Robert Goulet wrote: >> Patch attached for adding makefile to install generators. >> This refactoring is required for install(FILES) genex support, >> and most likely other install() signatures in the future. > > Thanks. I applied that and merged to

Re: [CMake] Determining a library name at configure time

On 09/18/2015 11:42 AM, Bill Newcomb wrote: Suppose I add a library in my project: add_library(foo STATIC foo.c bar.c) Is there a way I can get the name of the generated library file at configure time? LIBRARY_OUTPUT_NAME and OUTPUT_NAME for the target do not seem to be set: Can you

Re: [CMake] Determining a library name at configure time

On 09/18/2015 02:42 PM, Bill Newcomb wrote: > Suppose I add a library in my project: > > add_library(foo STATIC foo.c bar.c) > > Is there a way I can get the name of the generated library file at > configure time? On multi-configuration generators like VS and Xcode there may be more than one

Re: [CMake] How to create a custom solution with Visual Studio 2010 generator?

> -Original Message- > From: J Decker [mailto:d3c...@gmail.com] > Sent: Tuesday, September 22, 2015 8:12 AM > To: Golebiewski, Jakub > Cc: cmake@cmake.org > Subject: Re: [CMake] How to create a custom solution with Visual Studio > 2010 generator? > > On Mon, Sep 21, 2015 at 10:39 PM,

Re: [CMake] How to create a custom solution with Visual Studio 2010 generator?

On Mon, Sep 21, 2015 at 10:39 PM, Golebiewski, Jakub wrote: > This may be a solution, I will check this asap. > > This should be clearer, I have something like this: > > Main Project - PROJECT() > \Sub Project 1 - PROJECT() >

Re: [cmake-developers] Generator expressions for install destination

On 09/22/2015 09:58 AM, Robert Goulet wrote: > Patch attached for adding makefile to install generators. > This refactoring is required for install(FILES) genex support, > and most likely other install() signatures in the future. Thanks. I applied that and merged to 'next' for testing:

Re: [cmake-developers] Generator expressions for install destination

Thanks, once this is accepted in master I will send you my updated install(FILES) with genex support. I removed the GetDestination() signature since I agree it's not needed and might be confusing. -Original Message- From: Brad King [mailto:brad.k...@kitware.com] Sent: Tuesday,

Re: [CMake] Does CMake 3.3.1 ignore CXX env variable on OSX10.10?

On 22.09.2015 17:53, Pere Mato Vila wrote: Thanks Nils. This explains it. So, the value of CXX is not honored. I wouldn't go that far given that /usr/bin/clang++ and cmake call the same compiler. If you were to use a compiler in a custom installation prefix (without apple's tool in between)

[Cmake-commits] CMake branch, next, updated. v3.3.2-3209-g5a93c93

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 5a93c936996b87d748da707058b374f2f71e25ca (commit) via

Re: [cmake-developers] Regression caused by compute-default-dialect topic

Brad King wrote: > On 09/16/2015 03:14 PM, Brad King wrote: >> That eliminates my concern. > > This is now in 'master' as: > > Project: Determine default language dialect for the compiler. > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7235334a > > However, I just discovered that it

Re: [cmake-developers] CMakeForceCompiler (was: Regression caused by compute-default-dialect topic)

On 09/22/2015 04:29 PM, Stephen Kelly wrote: > I've pushed fix-forced-toolchain-dialect to fix this. It uses an existing > mechanism already in use to determine whether the compiler was forced. Looks good, thanks. > Is there any legitimate need to force the compiler? The CMakeForceCompiler

[cmake-developers] Help with diagnosing dashboard failure

Hi, A few days ago I merged a commit which moves the construction of cmLocalGenerator objects. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a3aa333d It fails on the RunCMake.try_compile test on several dashboards in the CMP0056 test at the end where the policy is set to NEW. I

Re: [CMake] Determining a library name at configure time

Disclaimer: The system I'm working on has its origins in pre cmake-2.6 days, and we'd probably make a lot of different decisions if we started anew today. We are using only the Unix Makefiles generator. Our system comprises a number of components, each of which is its own cmake project, and

Re: [cmake-developers] Generator expressions for install destination

On 09/22/2015 04:35 PM, Robert Goulet wrote: > Ok so that brings the question, how is 3.4 schedule looking? The feature freeze will be Oct 1 shortly after which post-3.4 development will open. Steve will then start his post-3.4 refactoring topic merges and then we can come back to this feature.

[Cmake-commits] CMake branch, next, updated. v3.3.2-3211-g0cea45e

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 0cea45e48783bb37d60f067c0e6a658b7ac84757 (commit) via

Re: [cmake-developers] Generator expressions for install destination

On 09/22/2015 04:00 PM, Stephen Kelly wrote: > This is going in the wrong direction. > (Merge topic 'generators-use-cmLocalGenerator', 2015-08-24) > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9135e370 [snip] > The patch from Robert should not undo that effort, so the branch > should be

Re: [cmake-developers] Generator expressions for install destination

Ok then perhaps the refactoring can wait but we'd still like to get install(FILES) destination genex support in 3.4 if possible, and genex evaluation requires the cmMakefile. How should we proceed then? -Original Message- From: cmake-developers

Re: [cmake-developers] Generator expressions for install destination

Yeah I guess it could look something like this (attachment). However I just realized that if I don't also get install(DIRECTORY) in 3.4 then this is not worth rushing it, since as you mention I would also need to write proper test cases. Just let me know when I can start looking at this again

Re: [CMake] Determining a library name at configure time

On 22.09.2015 23:17, Bill Newcomb wrote: Disclaimer: The system I'm working on has its origins in pre cmake-2.6 days, and we'd probably make a lot of different decisions if we started anew today. We are using only the Unix Makefiles generator. Our system comprises a number of components,

Re: [cmake-developers] Generator expressions for install destination

Brad King wrote: > On 09/22/2015 04:00 PM, Stephen Kelly wrote: >> This is going in the wrong direction. >> (Merge topic 'generators-use-cmLocalGenerator', 2015-08-24) >> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9135e370 > [snip] >> The patch from Robert should not undo that effort,

Re: [cmake-developers] Generator expressions for install destination

Ok so that brings the question, how is 3.4 schedule looking? We really wanted to get install(FILES) destination genex in CMake 3.4 release version... this is a bit disappointing because we'll have to stick with our custom branch another round. Oh well. Thanks. -Original Message- From:

Re: [cmake-developers] [CMake] Visual Studio - Ninja Generator

James Johnston wrote: >> > it would be useful to have Visual Studio available as an "Extra" CMake >> > generator. For example, specification of "Visual Studio 2015 - Ninja" >> >> This functionality sounds reasonable but the name of the extra/generator >> pair looks funny when spelled out that

Re: [cmake-developers] Generator expressions for install destination

Robert Goulet wrote: > Ok then perhaps the refactoring can wait but we'd still like to get > install(FILES) destination genex support in 3.4 if possible, and genex > evaluation requires the cmMakefile. How should we proceed then? cmLocalGenerator has a GetMakefile method (currently). Don't you

Re: [cmake-developers] Generator expressions for install destination

Robert Goulet wrote: > Yeah I guess it could look something like this (attachment). Yes, something like that (modulo the long line). > However I > just realized that if I don't also get install(DIRECTORY) in 3.4 then this > is not worth rushing it, since as you mention I would also need to

[Cmake-commits] CMake branch, master, updated. v3.3.2-1261-g44f2ade

_VERSION_MINOR 3) -set(CMake_VERSION_PATCH 20150922) +set(CMake_VERSION_PATCH 20150923) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

Re: [cmake-developers] [Patch] Adding Windows 10 support

Thanks for the feedback Brad, I have rebased the changes and I think that I have the proper default functionality properly implemented. I've extracted the WINDOWS_TARGET_PLATFORM_VERSION changes into a separate patch. WINDOWS_TARGET_PLATFORM_VERSION is a target property, for that will specify

[Cmake-commits] CMake branch, next, updated. v3.3.2-3203-g95c3902

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 95c39028ede8b8ba988f6d0f6964b0f7ce2bf76b (commit) via

Re: [CMake] Does CMake 3.3.1 ignore CXX env variable on OSX10.10?

Thanks Nils. This explains it. So, the value of CXX is not honored. The problem we have, is that we record the compiler that we have used to build for runtime usage. If we make a binary distribution, this one will we used by clients that may have the compiler somewhere else. Cheers,

Re: [CMake] add_library(foo SHARED...) is not creating a PDB file

On Tue, Sep 22, 2015 at 11:19 AM, Brad King wrote: > On 09/22/2015 11:16 AM, Tom Kacvinsky wrote: > > having two builds (debug and release) doesn't fit our workflow > > Try using the RelWithDebInfo configuration. > > Eeeek, that won't work because we are also using Ada and

Re: [CMake] How to create a custom solution with Visual Studio 2010 generator?

> I've tried running cmake independently for each subproject but I get errors > about unknown > Targets since every Sub Project depends on targets from 'earlier' one. > > I have about 620 targets (VS projects) so when I open Main Project.sln (with > 620 projects) in VS it is impossible to work

Re: [CMake] add_library(foo SHARED...) is not creating a PDB file

On 09/22/2015 09:25 AM, Tom Kacvinsky wrote: > I am using cmake 2.8.11.2 on Windows 7 with Visual Studio 2008 [snip] > whether listing the object files or compiling from source, there is > the cl option to create PDB debugging information. Please try with CMake 3.1 or higher:

Re: [CMake] add(library foo SHARED...) is not creating a PDB file

On Mon, Sep 21, 2015 at 5:37 PM, Tom Kacvinsky wrote: > I am using cmake 2.8.11.2 on Windows 7 with Visual Studio 2008 > > This is the snipped of my CMakeLists.txt file > > add_library(commoncpp_objects > OBJECT > > ) > >

Re: [CMake] How to create a custom solution with Visual Studio 2010 generator?

Hi, Am 22. September 2015 08:49:57 MESZ, schrieb "Golebiewski, Jakub" : >I have about 620 targets (VS projects) so when I open Main Project.sln >(with 620 projects) in VS it is impossible to work with. >Currently cmake produces .sln for each Sub Project but includes

Re: [cmake-developers] [CPackDeb] empty directories in packages

> I was looking at this issue > http://public.kitware.com/Bug/view.php?id=13009 > > and apparently it is not possible to install empty directories (I just > tested). > > I believe that it should be possible to do that (even if there are better > ways like postinst). > What is your opinion? I

Re: [cmake-developers] [CPackDeb] empty directories in packages

Domen Vrankar wrote: I was looking at this issue http://public.kitware.com/Bug/view.php?id=13009 and apparently it is not possible to install empty directories (I just tested). I believe that it should be possible to do that (even if there are better ways like postinst). What is your

[CMake] Does CMake 3.3.1 ignore CXX env variable on OSX10.10?

Hi, On previous versions I was setting the variables CC and CXX to force the compiler. This is not working anymore. Is this intended? Cheers, Pere ——— macitois13:test sftnight$ cmake --version cmake version 3.3.1 CMake suite maintained and supported by Kitware

Re: [cmake-developers] [CPackDeb] empty directories in packages

> You left a commented out line in Source/CPack/cmCPackGenerator.cxx. Hm that should not be there. I'll delete it when I get to my PC. Thanks, Domen -- 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

Re: [CMake] Does CMake 3.3.1 ignore CXX env variable on OSX10.10?

Hi Pere, > On 22 Sep 2015, at 11:18, Pere Mato Vila wrote: > > Hi, > > On previous versions I was setting the variables CC and CXX to force the > compiler. This is not working anymore. Is this intended? > Cheers, > I think it *is* honouring CC/CXX, but from CMake 3.2

Re: [CMake] Does CMake 3.3.1 ignore CXX env variable on OSX10.10?

On 09/22/2015 04:43 PM, Pere Mato Vila wrote: Hi Ben, Thanks, but in my case CXX is already a full path (/usr/bin/clang++). It is set like this export CXX=`which clang++` I do not understand how /usr/bin/clang++ gets converted to

Re: [CMake] add_library(foo SHARED...) is not creating a PDB file

On Tue, Sep 22, 2015 at 9:57 AM, Tom Kacvinsky wrote: > > > On Tue, Sep 22, 2015 at 9:41 AM, Brad King wrote: > >> On 09/22/2015 09:25 AM, Tom Kacvinsky wrote: >> > I am using cmake 2.8.11.2 on Windows 7 with Visual Studio 2008 >> [snip] >>

Re: [CMake] Does CMake 3.3.1 ignore CXX env variable on OSX10.10?

Hi Ben, Thanks, but in my case CXX is already a full path (/usr/bin/clang++). It is set like this export CXX=`which clang++` I do not understand how /usr/bin/clang++ gets converted to /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++

[Cmake-commits] CMake branch, master, updated. v3.3.2-1252-gda7c8a8

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 da7c8a8dae10a4fd2f33798bc8aec8a3c238b2af (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.2-1260-g442d17e

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 442d17ef6c50a3ffc83ed6a860dc05febd85f1b4 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.2-1257-gfcd9f85

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 fcd9f85660bb0de569a5a5770b98eb7d922fbd6b (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.2-3192-g84ae6a6

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 84ae6a68a62b3739015dba75a785ae6b939a882a (commit) via

[cmake-developers] Regression caused by compute-default-dialect topic

On 09/16/2015 03:14 PM, Brad King wrote: > That eliminates my concern. This is now in 'master' as: Project: Determine default language dialect for the compiler. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7235334a However, I just discovered that it breaks use of toolchain files that

Re: [cmake-developers] Add command line options for deprecation message control

On 09/21/2015 05:51 PM, Michael Scott wrote: > Yes the -Werr-dev, -Wno-err-dev, -Werr-deprectated and > -Wno-err-deprecated may be trickier than expected to get behaving as > intended. I'll try and get a better idea of the users of IssueMessage > and see if some ideas come to mind. Removing

Re: [CMake] add_library(foo SHARED...) is not creating a PDB file

On Tue, Sep 22, 2015 at 9:41 AM, Brad King wrote: > On 09/22/2015 09:25 AM, Tom Kacvinsky wrote: > > I am using cmake 2.8.11.2 on Windows 7 with Visual Studio 2008 > [snip] > > whether listing the object files or compiling from source, there is > > the cl option to create

Re: [cmake-developers] Generator expressions for install destination

> This and its related changes are also refactoring that should go in its own > commit. Ok let's begin with this. Patch attached for adding makefile to install generators. This refactoring is required for install(FILES) genex support, and most likely other install() signatures in the future.

[Cmake-commits] CMake branch, next, updated. v3.3.2-3185-g096946b

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 096946bd49b2342a347c700947b5fdf930f6cc08 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.2-1249-g4be709a

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 4be709a6b715acb4100fceb4394ad5215d8b555b (commit) via

[Cmake-commits] CMake branch, master, updated. v3.3.2-1247-gf1365f3

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 f1365f32064d6e56c1cbdf27bb18b9c7a8490330 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.3.2-3195-gda0bdab

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 da0bdab6d9788728bf0671b22a287dd1b5517f42 (commit) via

Re: [CMake] add_library(foo SHARED...) is not creating a PDB file

On 09/22/2015 11:16 AM, Tom Kacvinsky wrote: > having two builds (debug and release) doesn't fit our workflow Try using the RelWithDebInfo configuration. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

[Cmake-commits] CMake branch, next, updated. v3.3.2-3197-geb99bf2

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 eb99bf2d6861ba6cfc282265a5947453032c68dc (commit) via

Re: [CMake] How to create a custom solution with Visual Studio 2010 generator?

Just as a point of information illustrating the opposite, we like using a CMakeList file for each target that contains a project() command where the name of the project is the name of the target. This is nice (for us) in that you get many .sln files generated from the larger source tree where you