Re: [cmake-developers] compile_feature test results
Brad King wrote: > On 11/12/2013 09:40 AM, Brad King wrote: >> The compile feature tests are basically doing the same kind of tests >> as the compiler id, so the same approach should work. > > Note that the Modules/CompilerId/* project files do have some content > specific to the compiler id step. Therefore a separate set should > be used for this feature. > > I suggest the following steps: > > 1. Revert the target_compile_features topic until this is resolved. Done. Rebased to master and pushed to my clone. > 2. Create a new topic that adds a *test* in which you build the >new infrastructure. (This way all the trial and error will be >isolated to a single test and other topics can proceed without >interference.) > > 3. Once the test works everywhere, the actual infrastructure can >be ported over to the Modules directory and the test can just >exercise it. I'm not claiming these tasks, so they're up for grabs (Eike?). I'm refocusing on cross-compiling-toolchain-variables, because for me it is a higher priority to get that "done done". I also have other topics which can be done in parallel, but I'll defer them until that topic is in to eliminate distraction (at least as far as it comes from me :) ). Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Cross compiling toolchain variables
Brad King wrote: > IMO it should probably be transformed to the full SDK path in CMake > code, using the logical name only in CMakeCache.txt and for the Xcode > generator. I think we can do this with no attempt at compatibility > because projects must always deal with users setting the value to > a path already (and this variable is undocumented anyway). > > Would this change your conclusion? My general lack of familiarity with OSX/Xcode/Mac sdks remains, and that is what makes me continue to prefer option 3. > Since none of us seems to understand how to properly merge these > features, perhaps it is simplest to keep them separate. Once both > have been around for a while perhaps their relationship will be > more clear. In my understanding, the distinction can simply be > that CMAKE_OSX_SYSROOT is for OS X -> OS X builds, and CMAKE_SYSROOT > is for cross compiling. Yes. If we can consider that decided, then the remaining issue relates to CMAKE_INSTALL_PREFIX. If I can implement that as I wrote previously, this topic is done. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Review request: set_emptyvar_PARENT_SCOPE
On 11/11/2013 05:13 AM, Daniele E. Domenichelli wrote:
> I've pushed a patch to the set_emptyvar_PARENT_SCOPE topic.
The first commit that adds a period to the summary of CMP0039
is a separate change, so I've taken that out into a separate
'policy-summary-periods' topic which is now in 'next'. Thanks.
Here are a few comments on the main change:
+ this->DefinePolicy(
+CMP0040, "CMP0040",
+"set(var "" PARENT_SCOPE) no longer unset var.",
+3,0,0,0, cmPolicies::WARN);
You need to escape the quotes inside the string here.
This hunk is important:
+ // SET (VAR PARENT_SCOPE) // Removes the definition of VAR
+// in the parent scope.
+ else if (args.size() == 2 && args[args.size()-1] == "PARENT_SCOPE")
+{
+this->Makefile->RaiseScope(variable, 0);
+return true;
+}
and should be taken regardless of the decision below.
One problem with the policy is that it warns more than necessary.
The difference between set-to-empty and unset is only visible in
"if(DEFINED VAR)" tests and not in "${VAR}". Implementing a policy
that warns only when there will actually be a difference in behavior
will be very difficult. Also the combination of code needed to
observe a difference in behavior is quite obscure.
In the current behavior:
set(VAR) # same as unset(VAR)
set(VAR PARENT_SCOPE) # same as unset(VAR PARENT_SCOPE)
set(VAR "") # sets to empty
and the documentation agrees. Furthermore, the case in question
set(VAR "" PARENT_SCOPE)
is documented as setting to empty in the parent scope already.
It is only the implementation that is buggy. I think we can assume
that anyone who writes this code intends to set to empty rather than
unset in the parent scope, and is likely using just ${VAR} and does
not know the difference.
Therefore I think we can actually skip the policy in this case and
simply treat this as a bug fix, especially given that the change will
come with a major version number.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Cross compiling toolchain variables
On 11/09/2013 06:08 AM, Stephen Kelly wrote: > 1) The user sets the CMAKE_SYSROOT to a path *or* a OSX SDK name. CMake > transforms it to a path if it is an SDK name, so that in CMake code, > CMAKE_SYSROOT is always a path. > > 2) The user continues to set CMAKE_OSX_SYSROOT, but CMake sets the > CMAKE_SYSROOT variable to either the path, if it is a path, or the > transformed result of an SDK name. [snip] > So, I think, without knowing more than the above, I prefer option 3: Don't > merge the features. Note that we didn't always support a logical name in CMAKE_OSX_SYSROOT. It was added in CMake 2.8.10: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1786b121 IMO it should probably be transformed to the full SDK path in CMake code, using the logical name only in CMakeCache.txt and for the Xcode generator. I think we can do this with no attempt at compatibility because projects must always deal with users setting the value to a path already (and this variable is undocumented anyway). Would this change your conclusion? Since none of us seems to understand how to properly merge these features, perhaps it is simplest to keep them separate. Once both have been around for a while perhaps their relationship will be more clear. In my understanding, the distinction can simply be that CMAKE_OSX_SYSROOT is for OS X -> OS X builds, and CMAKE_SYSROOT is for cross compiling. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Drop configure_file(IMMEDIATE) in 3.0?
On 11/12/2013 11:24 AM, Daniele E. Domenichelli wrote: > I also noticed that there are still a lot of cmake modules (just try > "git grep IMMEDIATE Modules" ) and a lot of cmake files for other > projects that use this ignored option, and they keep spreading to the > copy-paste power. > > Since I recently saw a lot of new policies that disable old commands, > maybe this is a good moment to add a policy and a warning for this as well? Let's start with a change that removes all uses from CMake-provided modules. This is only now possible because prior to the post-2.8.12 change: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7d47c693#patch6 we needed IMMEDIATE in the modules to support ancient compatibility levels. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Drop configure_file(IMMEDIATE) in 3.0?
Hi,
the configure_file(IMMEDIATE) argument was deprecated since 2.2 or
something similar (commit c9cc368a9db33273ad6287ea94fc285e90c4901f, Jun
2005).
Nonetheless the IMMEDIATE arguments is still accepted without even
issuing a warning:
else if(args[i] == "IMMEDIATE")
{
/* Ignore legacy option. */
}
I also noticed that there are still a lot of cmake modules (just try
"git grep IMMEDIATE Modules" ) and a lot of cmake files for other
projects that use this ignored option, and they keep spreading to the
copy-paste power.
Since I recently saw a lot of new policies that disable old commands,
maybe this is a good moment to add a policy and a warning for this as well?
Cheers,
Daniele
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja pools
On 11/09/2013 06:39 AM, Peter Kümmel wrote: > On 08.11.2013 17:22, Brad King wrote: >> Without context the name "POOL" may not have clear meaning to >> a reader not already familiar with Ninja's feature. I think >> a name like JOB_POOL would be clearer. > > Even JOB_POOL leaves the question what a "pool" is. > I think it would be better to completely drop "pool", and to use > something more obvious like PARALLEL_JOBS IMO the name "JOB_POOL" is clear enough. It is distinct and can be used to locate information about the feature. > I would prefer to create a semantic which also fits for other generators > and not to use the NINJA prefix. How could the limiting be very different > for other generators? It always reduces the number of parallel processes. > > Maybe a property for just disabling parallel execution at all is enough. > I couldn't imagine use cases where the fine-grained pool control > of ninja is needed. Such a simplifies interface should also be > compatible with other generators, and would be very strict, as requested. On second thought the semantics are already pretty general. If needed then future support in other generators could add restrictions like a max pool size or something. Since this is still experimental I'd rather not add an option to add_custom_command for it yet. Let's just go with global property JOB_POOLS to configure the pools, target properties JOB_POOL_LINK JOB_POOL_COMPILE JOB_POOL_CUSTOM to map rules to the pools, and variables CMAKE_JOB_POOL_LINK CMAKE_JOB_POOL_COMPILE CMAKE_JOB_POOL_CUSTOM to initialize the mapping in each target. A future option to add_custom_command could override JOB_POOL_CUSTOM but the simple default will allow projects to quickly group everything without marking up all their targets or custom commands. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] compile_feature test results
On 11/12/2013 09:40 AM, Brad King wrote: > The compile feature tests are basically doing the same kind of tests > as the compiler id, so the same approach should work. Note that the Modules/CompilerId/* project files do have some content specific to the compiler id step. Therefore a separate set should be used for this feature. I suggest the following steps: 1. Revert the target_compile_features topic until this is resolved. 2. Create a new topic that adds a *test* in which you build the new infrastructure. (This way all the trial and error will be isolated to a single test and other topics can proceed without interference.) 3. Once the test works everywhere, the actual infrastructure can be ported over to the Modules directory and the test can just exercise it. 4. Rebuild target_compile_features using this new run-compiler feature. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] compile_feature test results
On 11/12/2013 06:06 AM, Nils Gladitz wrote:
> On 11/12/2013 10:34 AM, Stephen Kelly wrote:
>> I don't know why the CMAKE_CXX_COMPILE_FEATURES is not correct. Any ideas?
>>
> When I run the SystemInformation test from a regular command line I get
> errors about mspdb100.dll missing from the cl.exe instances being launched.
> This results in missing CMAKE_CXX_COMPILE_FEATURES.
>
> When I run it from a visual studio command prompt then the test works
> and the variable is set.
Steve, running the compiler with execute_process is apparently
going to be quite difficult to do portably. Running "cl" will
require launching a wrapper .bat script that loads the right
VS environment. To do this generally will require much more of
an abstraction than _CMAKE_${lang}_CREATE_OBJECT_FILE provides
right now.
The closest we come to doing this now is in
Modules/CMakeDetermineCompilerId.cmake where for the VS and Xcode
generators we actually generate a hand-coded mini project file
and build it using the IDE. In the other generators we just run
the compiler directly through execute_process. Together these
approaches allow us to build the single compiler id source file
in all the generators without loading any environment. The
compile feature tests are basically doing the same kind of tests
as the compiler id, so the same approach should work.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake variable documentation containing <>
On 11/10/2013 03:29 PM, Nils Gladitz wrote: > After adding documentation for new variables I noticed that for e.g.: > CPACK_WIX__EXTENSIONS > only CPACK_WIX__EXTENSIONS shows up in the search results. > > Same seems to be the case for existing documentation for variables like > CMAKE__FLAGS: > http://www.cmake.org/cmake/help/git-master/search.html?q=_FLAGS > > Is there something that can/should be done about that? It looks like only the page rendering of the search results that is incorrect. The generated html code has correct links but the text of the link is generated as variable:CMAKE__FLAGS instead of variable:CMAKE__FLAGS It is likely a bug in Shpinx, perhaps in "searchtools.js". -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using -g3 in Debug config?
On 11/12/2013 05:20 AM, Stephen Kelly wrote: > KDE adds a DebugFull configuration which uses -g3 instead of -g. Would a > patch changing Debug to use -g3 be accepted? I am told it adds support for > macro expansion in the debugger. Regardless of the generalizations suggested in my sibling response, we should not change a default like this outright. Can you propose a compatible way to do it that will not make every project change? -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using -g3 in Debug config?
Brad King wrote: > Alternatively, perhaps it is time to generalize debugging and optimizing > flags like preprocessor defs, -fPIC, etc. have been generalized. ... and warnings/errors etc http://public.kitware.com/Bug/view.php?id=3811 That could be done/justified independently of other suggested changes. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Using -g3 in Debug config?
On 11/12/2013 05:20 AM, Stephen Kelly wrote: > KDE adds a DebugFull configuration which uses -g3 instead of -g. Would a > patch changing Debug to use -g3 be accepted? I am told it adds support for > macro expansion in the debugger. Just about every default flag in one of standard CMake configurations has been "wrong" for someone at some point. Perhaps we need to provide an easier way for projects to select default flags on a per-toolchain basis. Alternatively, perhaps it is time to generalize debugging and optimizing flags like preprocessor defs, -fPIC, etc. have been generalized. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] compile_feature test results
On 11/12/2013 10:34 AM, Stephen Kelly wrote: I don't know why the CMAKE_CXX_COMPILE_FEATURES is not correct. Any ideas? When I run the SystemInformation test from a regular command line I get errors about mspdb100.dll missing from the cl.exe instances being launched. This results in missing CMAKE_CXX_COMPILE_FEATURES. When I run it from a visual studio command prompt then the test works and the variable is set. I assume the same is true on the failing dashboard since coincidentally CMAKE_RC_COMPILER is set to "RC" without the visual studio environment and to the full path of rc.exe with the environment. Nils -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014563]: Embed binary/resource file functionality
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14563 == Reported By:Domagoj Saric Assigned To: == Project:CMake Issue ID: 14563 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2013-11-12 05:36 EST Last Modified: 2013-11-12 05:36 EST == Summary:Embed binary/resource file functionality Description: Please add functionality that would provide a portable way of embedding arbitrary files into projects whose raw/binary data can then be accessed from source code: - *NIX/GCC http://stackoverflow.com/questions/2627004/embedding-binary-blobs-using-gcc-mingw?lq=1 - Windows: http://stackoverflow.com/questions/2740164/how-to-embed-link-binary-data-into-a-c-dll - standard C: http://stackoverflow.com/questions/11813271/embed-resources-eg-shader-code-images-into-executable-library-with-cmake == Issue History Date ModifiedUsername FieldChange == 2013-11-12 05:36 Domagoj Saric New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Using -g3 in Debug config?
Hello, KDE adds a DebugFull configuration which uses -g3 instead of -g. Would a patch changing Debug to use -g3 be accepted? I am told it adds support for macro expansion in the debugger. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] compile_feature test results
Hello, http://open.cdash.org/testDetails.php?test=217955130&build=3096545 shows that CMAKE_CXX_COMPILE_FEATURES == "" I expect it to contain msvcxx_sealed. On the MSVC10 machine I have access to, that is the result. http://open.cdash.org/testDetails.php?test=217955198&build=3096545 shows the feature_tests.cxx content which I expect. I don't know why the CMAKE_CXX_COMPILE_FEATURES is not correct. Any ideas? As a counter-example, http://open.cdash.org/testDetails.php?test=217940230&build=3096432 is correct. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014562]: not able to compile a simple test program with -G "Visual Studio 11 2012" -Tv90
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14562 == Reported By:Kiron Assigned To: == Project:CMake Issue ID: 14562 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-11-12 03:33 EST Last Modified: 2013-11-12 03:33 EST == Summary:not able to compile a simple test program with -G "Visual Studio 11 2012" -Tv90 Description: CMake 2.8.12 (and 2.8.11) is unable to generate a VS 11 2012 project with toolset v90 and Visual Studio 11 2012 generator. CMake produces the following error: > cmake -H. -Bbuild-vs11Tv90 -G "Visual Studio 11 2012" -Tv90 -- The C compiler identification is MSVC 15.0.30729.1 -- The CXX compiler identification is MSVC 15.0.30729.1 -- Check for working C compiler using: Visual Studio 11 2012 -- Check for working C compiler using: Visual Studio 11 2012 -- broken CMake Error at C:/xxx/cmake/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/bin/cl.exe" is not able to compile a simple test program. It fails with the following output: Change Dir: C:/xxx/build-vs11Tv90/CMakeFiles/CMakeTmp Run Build Command:C:\PROGRA~2\MICROS~3.0\Common7\IDE\devenv.com CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec3158555336 Microsoft (R) Microsoft Visual Studio 2012 Version 11.0.60610.1. Copyright (C) Microsoft Corp. All rights reserved. The operation could not be completed. Wrong Parameter. Use: devenv [solutionfile | projectfile | anyfile.ext] [switches] The first argument for devenv is usually a solution file or project file. ... BUT it works when using the Visual Studio 10 2010 generator: > cmake -H. -Bbuild-vs10Tv90 -G "Visual Studio 10 2010" -Tv90 -- The C compiler identification is MSVC 15.0.30729.1 -- The CXX compiler identification is MSVC 15.0.30729.1 -- Check for working C compiler using: Visual Studio 10 2010 -- Check for working C compiler using: Visual Studio 10 2010 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Visual Studio 10 2010 -- Check for working CXX compiler using: Visual Studio 10 2010 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: C:/xxx/build-vs10Tv90 Steps to Reproduce: Run following command with an empty CMakeLists.txt in the current directory: > cmake -H. -Bbuild-vs11Tv90 -G "Visual Studio 11 2012" -Tv90 This fails, but following commands works: > cmake -H. -Bbuild-vs10Tv90 -G "Visual Studio 10 2010" -Tv90 == Issue History Date ModifiedUsername FieldChange == 2013-11-12 03:33 Kiron New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014561]: Errors with add_libaray(name INTERFACE) when TARGET_SUPPORTS_SHARED_LIBS is false
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14561 == Reported By:Kiron Assigned To: == Project:CMake Issue ID: 14561 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-11-12 03:22 EST Last Modified: 2013-11-12 03:22 EST == Summary:Errors with add_libaray(name INTERFACE) when TARGET_SUPPORTS_SHARED_LIBS is false Description: cmake version 2.8.12.2013-g13da When using add_libaray(name INTERFACE) command the following warnings/errors are reported by cmake when TARGET_SUPPORTS_SHARED_LIBS is FALSE. Embedded cross compile targets usually do not support shared libs. (see also Steps To Preproduce) > cmake -H. -Bbuild -- Building for: Visual Studio 11 2012 -- The C compiler identification is MSVC 17.0.60610.1 -- The CXX compiler identification is MSVC 17.0.60610.1 -- Check for working C compiler using: Visual Studio 11 2012 -- Check for working C compiler using: Visual Studio 11 2012 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Visual Studio 11 2012 -- Check for working CXX compiler using: Visual Studio 11 2012 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Warning (dev) at CMakeLists.txt:6 (add_library): ADD_LIBRARY called with MODULE option but the target platform does not support dynamic linking. Building a STATIC library instead. This may lead to problems. This warning is for project developers. Use -Wno-dev to suppress it. You have called ADD_LIBRARY for library foo without any source files. This typically indicates a problem with your CMake Lists.txt file -- Configuring done CMake Error: CMake can not determine linker language for target: foo -- Generating done -- Build files have been written to: C:/xxx/build > echo %ErrorLevel% 1 Steps to Reproduce: Create CMakeLists.txt with following content: cmake_minimum_required(VERSION 2.8.12.20131009) set_property(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE) add_library(foo INTERFACE) run following command: cmake -H. -Bbuild echo %ErrorLevel% == Issue History Date ModifiedUsername FieldChange == 2013-11-12 03:22 Kiron New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
