[cmake-developers] How to handle configurations (Was: Generating buildsystem metadata from CMake)

This seems to be to be a design point which we are blocked on. There are many different ideas floating around. I think we need to talk about what would be generated for actual CMakeLists files, and how tools would parse the result. I suggest starting with the Tests/Metadata/CMakeLists.txt

Re: [cmake-developers] Extracting target metadata, IDE integration

Tobias Hunger wrote: This JSON file can be a step forward here: It is actually meant to be used by IDEs, it has a format straight forward to parse, it does not depend on the generator used, it will (hopefully;-) end up being documented, it provides versioning, etc. I see some potential there.

Re: [cmake-developers] Generating buildsystem metadata from CMake

Aleix Pol wrote: By 'in scope' you mean 'used by the primary CMakeLists.txt files via include() or find_package()' or something like that? OK, let's see if that's the best source of that data or if we should add something new internally in cmake. By in scope I mean whether a variable or a

Re: [cmake-developers] Generating buildsystem metadata from CMake

Nils Gladitz wrote: On 03/11/2015 11:10 AM, Stephen Kelly wrote: I'm starting to gather requirements and make sure the feature is well designed to satisfy the needs we're already aware of, and fits with the features CMake currently has. Source file groups (as in defined by source_group

Re: [cmake-developers] Extracting target metadata, IDE integration

Aleix Pol wrote: I just pushed my change into a github clone for easier testing and reviewing. https://github.com/aleixpol/CMake Hi Aleix, Thanks for your efforts. Here are some things that are required before a feature like this can be committed to the cmake repo: * Discuss the feature

Re: [cmake-developers] Generating buildsystem metadata from CMake

On Saturday, March 14, 2015, Aleix Pol aleix...@kde.org wrote: On Wed, Mar 11, 2015 at 11:10 AM, Stephen Kelly steve...@gmail.com wrote: Hi, Following from the thread here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394 http://thread.gmane.org

[cmake-developers] Generating buildsystem metadata from CMake

Hi, Following from the thread here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650 I'm starting to gather requirements and make sure the feature is well designed to satisfy

Re: [cmake-developers] Generating buildsystem metadata from CMake

On 03/11/2015 11:10 AM, Stephen Kelly wrote: Hi, Following from the thread here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12394 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12650 The discussion in that thread

Re: [cmake-developers] Generating buildsystem metadata from CMake

Stephen Kelly wrote: I expect to require a few iterations to figure out what the metadata files should contain in the end. Just FYI, I have not forgotten about this and am working on an expanded design to cover the reported needs. Thanks, Steve. -- Powered by www.kitware.com Please

Re: [cmake-developers] Generating buildsystem metadata from CMake

Anton Makeev wrote: The problem with the following format: --- include_directories : [/foo, /opt] compile_definitions : [DEF=\Foo\, OTHER_DEF=1] compile_flags: [ -c ] — Is that it’s incomplete and cannot be used directly: * include directories list misses compiler-defined search paths

Re: [cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)

Ben Boeckel wrote: Hi, I have a branch on my Github fork to support object library linking: object-library-linking https://github.com/mathstuf/CMake/tree/object-library-linking Thanks for working on this. There is also a commit which updates usage of $TARGET_OBJECTS to not

Re: [cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)

Brad King wrote: On 02/24/2015 05:25 PM, Stephen Kelly wrote: Until that problem is solved we cannot make object libraries implicitly offer their objects just through tll(). Honestly, the problem is still not clear to me. Consider an object library with some usage requirements

Re: [cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)

Ben Boeckel wrote: On Wed, Feb 25, 2015 at 22:57:13 +0100, Stephen Kelly wrote: What I envision for the future is: add_library(objlib OBJECT ...) target_compile_definitions(objlib PUBLIC MYDEF) target_sources(objlib INTERFACE $TARGET_OBJECTS:objlib) Do you envision

Re: [cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)

Ben Boeckel wrote: It is just as easy to get into this situation when linking static libraries, right? Object libraries are not part of the problem, right? Or could you post a sscce? It is, so maybe it's less of an issue. I just think it is much easier to stumble upon it when you start

Re: [cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)

Stephen Kelly wrote: For the diamond-usage problem, is there some way of utilizing the COMPATIBLE_INTERFACES to deny the mixing of two libraries where each built with an object libraries' objects? Having a property to trigger that would be nice... Yes, that's possible by adding

Re: [cmake-developers] Object library linking (and a bit about INTERFACE_SOURCES)

Brad King wrote: On 02/23/2015 07:50 PM, Ben Boeckel wrote: We could also lift the restriction then. I'm fine with just dropping the patch. Basically without it, all it blocks is add_custom_{command,target} from using $TARGET_OBJECTS…which could be useful for some obscure linker target CMake

[cmake-developers] Generator Expressions and packages (Was: target_link_libraries and --start-group/--end-group ?)

Robert Goulet wrote: Using Brad's method of link multiplicity is too much work because we make use of packages and heavy generator expressions, making it a lot more difficult and much less elegant. Hi Robert, We have not had much external feedback from the generator expressions and IMPORTED

Re: [cmake-developers] [PATCH] Generator expressions for XCODE_ATTRIBUTE

Brad King wrote: On 01/28/2015 02:14 PM, Gregor Jasny wrote: XCODE_ATTRIBUTE_TEST_HOST $TARGET_FILE:CocoaExample Would you consider applying the attached patch? It looks okay to me. Please extend the docs too

Re: [cmake-developers] Generating buildsystem metadata from CMake

Tobias Hunger wrote: and which kit (think set of compiler, Qt, some other settings) were used to in the built in that directory. Is this hypothetical? Currently I can add a compiler location and a Qt location in QtCreator, and I can create a kit and give it a name and partcular compiler

Re: [cmake-developers] How to handle configurations (Was: Generating buildsystem metadata from CMake)

Tobias Hunger wrote: Hi Stephen, On Sat, Mar 21, 2015 at 10:56 AM, Stephen Kelly steve...@gmail.com wrote: So, the design question I have is: * Is lots of repetition ok in the metadata file? If it can not be avoided, then so be it. It can be avoided at the cost of computation. I

[cmake-developers] Should Ninja be marked non-experimental?

Hi, Following from: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/11260/focus=12940 Brad King wrote: This was done with the Ninja generator when it was introduced, though fortunately in that case we didn't have to break anything IIRC. It is still documented as

Re: [cmake-developers] ExternalProject can't have interface library as a dependency

Andrey Pokrovskiy wrote: In my case openssl is also generated as a result of an external project, so I have to use INTERFACE library. Ah, ok. I missed that part. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] ExternalProject can't have interface library as a dependency

Andrey Pokrovskiy wrote: [Moved from cmake users mailing list] I have the following construction: ExternalProject_Add( websockets_ep DEPENDS ev openssl ...) But it so happened, that openssl is an INTERFACE library. It is an INTERFACE library, because I

Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?

Nils Gladitz wrote: On 04/28/2015 09:30 AM, Alan W. Irwin wrote: OK. Thanks, for pointing that out. Could you make that more obvious in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e. change the summary line from Disallow use of the LOCATION target property. == Disallow

Re: [cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add

Andrey Pokrovskiy wrote: Hi, I'm using cmake and CMAKE_TOOLCHAIN_FILE to build the project and it's dependencies. Some toolchain files have additional options (like API version, target architecture, linker type, etc.) which you need to pass to cmake command with -D in addition to the

Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake

Alan W. Irwin wrote: On 2015-04-28 14:54-0700 Alan W. Irwin wrote: Also, a spurious warning is probably not that big a deal, but if you think the incorrect order of project(...) before cmake_minimum_required(...) could lead to more serious issues now or in the future as Platform code gets

Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages

Domen Vrankar wrote: Usually what I do in such cases is - commit each patch separately to git - when I have to change one of them I just save commit messages, call git format-patch -5 HEAD where 5 is the amount of commits to the one that I wish to change - use git reset --soft HEAD^ to undo

[cmake-developers] MSVC 2015 RC CXX features

In case you missed it, http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx I didn't compare with the CMake compiler features file to see if it's different, but it will require first hand testing anyway, most likely. Thanks, Steve. -- Powered by

Re: [cmake-developers] Generating buildsystem metadata from CMake

Stephen Kelly wrote: The aim is to generate a structured file containing metadata relating the buildsystem. I've been quiet on this thread for a while, so I think it is time for an update. I became more ambitious in mid March and started prototyping a more-complete design for CMake IDE

Re: [cmake-developers] Generating buildsystem metadata from CMake

Ben Boeckel wrote: On Sat, Apr 04, 2015 at 14:32:51 +0200, Stephen Kelly wrote: However, there are other users of the compile-commands.json, so it will remain and the feature for generation of it will not be deprecated. Or, to be more clear - it doesn't need to be deprecated as a result

Re: [cmake-developers] Generating buildsystem metadata from CMake

On 04/02/2015 10:29 AM, Anton Makeev wrote: I see, but how will having include_directories help ‘Add include directory’-like actions? I mean, simply having this list (without additional info like backtraces) doesn’t seem to help much. We'll have to see :). So, in the end, we probably need

Re: [cmake-developers] Generating buildsystem metadata from CMake

Anton Makeev wrote: On 01 Apr 2015, at 00:41, Stephen Kelly steve...@gmail.com wrote: Anton Makeev wrote: The problem with the following format: --- include_directories : [/foo, /opt] compile_definitions : [DEF=\Foo\, OTHER_DEF=1] compile_flags: [ -c ] — Is that it’s incomplete

Re: [cmake-developers] Generating buildsystem metadata from CMake

Tobias Hunger wrote: On Wed, Apr 1, 2015 at 12:41 AM, Stephen Kelly steve...@gmail.com wrote: Anton Makeev wrote: The problem with the following format: --- include_directories : [/foo, /opt] compile_definitions : [DEF=\Foo\, OTHER_DEF=1] compile_flags: [ -c ] — Is that it’s incomplete

Re: [cmake-developers] Generating buildsystem metadata from CMake

Anton Makeev wrote: Not only do we reed it, we also have the UI that allows user to interact and the cached values. That means we’ll have CMakeCache parser anyways and do not need these values in metadata.json file, as it was mentioned in parallel discussion. Yes, that's what I thought. I

Re: [cmake-developers] A policy for Policies

Stephen Kelly wrote: Thanks for the clarification. I've added an entry to the release notes that CMP0011 is deprecated, and I can add something similar for CMP0003. Given what you wrote about the impact of making CMP0011 required, I've instead documented all policies = CMP0011 as deprecated

Re: [cmake-developers] A policy for Policies

Brad King wrote: On 06/06/2015 06:36 AM, Stephen Kelly wrote: The documentation notes that Policies are not feature toggles: http://www.cmake.org/cmake/help/git-master/manual/cmake-policies.7.html However, the reality is that Policies *are* feature toggles because they are so long-lived

Re: [cmake-developers] A policy for Policies

Brad King wrote: Also, no mention of this decision can be made in 3.3 because we are already past the deadline for that release. This isn't a 3.3 feature but a change to the documentation/release notes which is supposed to be ok? On 06/08/2015 03:52 PM, Stephen Kelly wrote: Given what you

Re: [cmake-developers] A policy for Policies

Brad King wrote: On 06/08/2015 04:15 PM, Stephen Kelly wrote: This isn't a 3.3 feature but a change to the documentation/release notes which is supposed to be ok? Yes, if the wording does not commit us to a specific future release. Even if the docs say 'the next release', we

[cmake-developers] A policy for Policies

Hi, The documentation notes that Policies are not feature toggles: http://www.cmake.org/cmake/help/git-master/manual/cmake-policies.7.html However, the reality is that Policies *are* feature toggles because they are so long-lived. Users have no expectation that Policies will 'stop working',

Re: [cmake-developers] A policy for Policies

Alex Merry wrote: I'm not sure the term REQUIRED_IF_USED is clear enough - I'm certainly confused by quite what you mean by it. You'll find it if you grep for it in cmake.git. The main reason for keeping policies around, as I see it, is to allow old projects to keep building with newer

Re: [cmake-developers] A policy for Policies

Stephen Kelly wrote: Setting a policy to REQUIRED_IF_USED in the cmake source means that if someone tries cmake_policy(SET CMP0011 OLD) they will get an informative error instead of no warning. Actually, that's not correct, sorry I wrote the explanation too quickly. What I described

Re: [cmake-developers] A policy for Policies

Stephen Kelly wrote: Setting a policy to REQUIRED_IF_USED in the cmake source means that if someone tries cmake_policy(SET CMP0011 OLD) they will get an informative error instead of no warning. Actually, that's not correct, sorry I wrote the explanation too quickly. What I described

Re: [cmake-developers] A policy for Policies

Brad King wrote: The intention originally was that the warning about the policy not being set would prompt project authors to port to the NEW behavior and set the policy. The only reason for the OLD setting is to disable the warning in stable release branches and such. It is also easy to

Re: [cmake-developers] A policy for Policies

Brad King wrote: snip I recommend the following guidelines: 1) Policies need to result in errors in a short timeframe. They are not something to ignore for years, because allowing that makes them feature toggles. Alex won't be happy with this one obviously, but that's what I recommend. 2)

Re: [cmake-developers] A policy for Policies

Brad King wrote: We designed policies to give projects smooth transitions from old to new behavior. If we suddenly make an error occur in code that currently works warning-free it will give policies and CMake a bad name. Ok. Actually I re-discovered this today in KDE4

Re: [cmake-developers] A policy for Policies

Brad King wrote: I think Fraser's point about the docs of each policy not explicitly mentioning deprecated is a major culprit there. I disagree. It is obvious that NEW is better than OLD. If it 'works' people will use it until they are forced not to, as Alex said. I expect most people doing

Re: [cmake-developers] Importing platform SDK libraries without a full path

Brad King wrote: It seems that the meaning of INTERFACE libraries is being overloaded with the opposite of their meaning. The meaning of INTERFACE is that it specifies usage requirements without itself building anything. In this, it is the same as IMPORTED libraries. A key distinction is

Re: [cmake-developers] Importing platform SDK libraries without a full path

Brad King wrote: On 05/27/2015 02:40 PM, Stephen Kelly wrote: By current 'design language' it is not a 'usage requirement', just like IMPORTED_LOCATION, LOCATION, $TARGET_FILE and others are not 'usage requirements'. Sure, but it does tell CMake what to do when a client consumes

Re: [cmake-developers] A policy for Policies

Brad King wrote: On 06/20/2015 05:29 AM, Stephen Kelly wrote: Even -Wno-dev should have no effect on the warning when the warning is unconditional. I think that makes sense. We would need to update the wording accordingly. I don't think more conditions with deprecation states is a good

Re: [cmake-developers] Has CMake been ported to z/OS

David Crayford wrote: z/OS really needs a port because cmake is starting to become common for new projects. Can you use GCC on that platform? If you can, then a good way forward would be to use GCC to compile CMake and create a Modules/Platform/ file for the platform. That would make CMake

Re: [cmake-developers] Importing platform SDK libraries without a full path

Brad King wrote: We cannot lift the requirement that IMPORTED_LOCATION be a full path because that is fundamental to the design of imported targets and is needed for things like $TARGET_FILE:... to work correctly. Could you add a unit test showing what happens when using that genex with a

Re: [cmake-developers] Importing platform SDK libraries without a full path

Brad King wrote: On 05/25/2015 08:27 AM, Stephen Kelly wrote: it should probably be an error to use TARGET_FILE on an INTERFACE target. That doesn't seem to currently be the case. We already reject that. I've added a test case to show this in another topic: Tests: Add case

Re: [cmake-developers] contributing to CMake

Michael Scott wrote: Hi Brad, Thanks! Initially I'd be looking for suggestions for entry tasks, then perhaps after some of those, if I see an area I'm particularly interested in I could propose contributions to those areas. Here are four bug reports which could be good starting points in

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

Chris Bieneman wrote: One big things I’m working on is improving the way we build our runtime libraries. These libraries are built for the targets that the compiler supports generating code for, so they can use different architectures, headers, and libraries than are used to build the

Re: [cmake-developers] cmState-definitions topic

Brad King wrote: Steve, I've merged most of this topic: Merge topic 'cmState-definitions' http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2370a994 Great, thanks! I think the last two commits on it: cmLinkedTree: Add API for size query and reserve.

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

Michael Scott wrote: Thanks for the comments, here is the previous patch, with the suggested amendments. Thanks for working on this. I'm wondering how these new command line options relate to the existing options -Wdev and -Wno-dev. Is there any reason not to make those existing options set

Re: [cmake-developers] A policy for Policies

Stephen Kelly wrote: Actually I re-discovered this today in KDE4 http://quickgit.kde.org/?p=kdelibs.gita=blobh=a9aecfd3hb=dde411c1f=cmake%2Fmodules%2FFindKDE4Internal.cmake#l349 KDE4 is 'done' from a development point of view. For several years there has been mainly only translation

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

Brad King wrote: On 07/27/2015 07:07 PM, Michael Scott wrote: I've changed the -W dev options to affect the deprecated warnings/errors as well, but only if the user hasn't used one of the options that control deprecated warnings (-Wdeprecated, -Wno-deprecated, -Werror=deprecated,

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

Brad King wrote: On 08/01/2015 04:03 AM, Stephen Kelly wrote: I still think it's a bit odd that policies and message(DEPRECATED) use a different semantic though (ie, message(DEPRECATED) should issue a warning by default unless -Wno-dev is used). ...or -Wno-deprecated That semantic

Re: [cmake-developers] [PATCH] Macro generation for relaxed constexpr

Jean-Michaël Celerier wrote: Qt 5 provides a macro for this context which expands to either 'const' or 'constexpr' depending on whether cxx_constexpr is available, and another macro which expands to either 'const' or 'constexpr' depending on whether cxx_relaxed_constexpr is available.

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

Re: [cmake-developers] Listing source-tree files encountered

Clifford Yapp wrote: With David's patch and the above SOURCE_DIR property, it looks like the necessary pieces are now present for target + source processing. That might happen to work for brlcad, but it is not really true. CMake looks in the source dir for relative files listed in targets,

Re: [cmake-developers] A policy for Policies

Brad King wrote: The lifecycle proposed in commit d5b1839a is way too aggressive. The end-Policy-lifetime topic looks nothing like the schedule or selection of policies discussed in the last few messages of this thread. Yes. The discussion died after my proposal. I've reverted the branch.

Re: [cmake-developers] Generating buildsystem metadata from CMake

Aleix Pol wrote: On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly steve...@gmail.com wrote: Stephen Kelly wrote: The aim is to generate a structured file containing metadata relating the buildsystem. I've been quiet on this thread for a while, so I think it is time for an update. I

Re: [cmake-developers] Adding an option for relative compiler invocations

Michael Enßlin michael@... writes: Over the last several decades, at least on the POSIX platform, it has become common practice to invoke compilers with relative file paths, and compilers have adopted to act accordingly. While the true culprit is the C standard's lax definition of __FILE__,

Re: [cmake-developers] Generator expressions for archive|library|runtime output directory

Robert Goulet wrote: Greetings! Patch in attachment for all OUTPUT_DIRECTORY variants to support generator expressions. Thanks! There are two signatures for cmCompiledGeneratorExpression::Evaluate. Did you use the correct one? Does this support all generator expressions? Including

Re: [cmake-developers] install(EXCLUDE_FROM_ALL) new feature - request for comment

Nick Lewis wrote: Thanks for working on this. I think it will be better discussed on the cmake-developers mailing list I find the title interesting but I didn't attempt to read the email. Please make a proposal instead of just dumping a tree of text which can not be followed:

Re: [cmake-developers] ARMCC toolchain support

Brad King wrote: > Our convention for the compiler id is to refer to the vendor or > maintaining > organization behind the compiler. Is that "MDK" ? + set(CMAKE_ASM${ASM_DIALECT}_COMPILER_ID_VENDOR_REGEX_ARMCC "MDK-ARM") -- Powered by www.kitware.com Please keep messages on-topic and

Re: [cmake-developers] use-correct-rcc-command-option topic

Brad King wrote: > Steve, > > In regard to: > > Revert "cmQtAutoGenerators: Fix rcc invocation for Qt 5.0 and 5.1 > (#15644)" https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=08147a9a > > The proper fix is to detect whether rcc supports --list or -list and user > the preferred one based

Re: [cmake-developers] ARMCC toolchain support

Andersson, Joakim wrote: > Hi. > > Sorry, forgot to add the actual patch, here it is. > Attached is a patch that adds support for the ARMCC toolchain. I saw this: +# add the target specific include directory: +get_filename_component(_compilerDir "${CMAKE_ASM_COMPILER}" PATH)

Re: [cmake-developers] use-correct-rcc-command-option topic

Brad King wrote: > On 10/27/2015 02:55 PM, Stephen Kelly wrote: >> I wanted to stick my pin in the map on this as the person >> who wrote the feature :). > > As the person that wrote this feature I expect you to maintain it, please. My idea of maintaining the featur

Re: [cmake-developers] CXX_STANDARD and linking

Brad King wrote: > I don't want CMake to generate broken builds by default. We *know* it > goes wrong on Solaris and cannot possibly work without user intervention. Just some more on this: The CMake 3.3 behavior of this is the same as it has always been since introducing compile-features for

Re: [cmake-developers] CMakeForceCompiler

Brad King wrote: > On 10/19/2015 10:46 AM, Brad King wrote: >> CMakeForceCompiler: Deprecate this module and its macros >> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5908dcb6 > > After fixing a typo in the commit message: > > CMakeForceCompiler: Deprecate this module and its macros

Re: [cmake-developers] ITK NIfTI broken Oct 6

Brad King wrote: > Prior to this change the variable would have the right value in > the subdirectory. Now it is not set. Please take a look. This command has been documented as deprecated for a long time. I notice this command is not covered by a policy.

Re: [cmake-developers] ITK NIfTI broken Oct 6

Brad King wrote: > On 10/12/2015 01:48 PM, Stephen Kelly wrote: >> This command has been documented as deprecated for a long time. >> >> I notice this command is not covered by a policy. > > Back when 3.0 deprecated a swath of old commands with policies > we decided

Re: [cmake-developers] Generating buildsystem metadata from CMake

Alexander Neundorf wrote: > Maybe this is of interest: the Eclipse CDT developers are currently > working on improved support for cmake: > https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206 > http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg29621.html Yes, I noticed that too a few days ago. My

Re: [cmake-developers] genex-generator-objects topic

Brad King wrote: > Steve, > > Last night's RunCMake.include test failures bisect to: > > cmMakefile: Store container of cmExportBuildFileGenerators. > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5925f99c > > A clang sanitizer build output is below. Please take a look. Looks like

Re: [cmake-developers] ITK NIfTI broken Oct 6

Brad King wrote: > Therefore we see that CMAKE_CURRENT_SOURCE_DIR is incorrectly set. > This CMakeLists.txt file is again entered by the subdirs() command > in the parent directory. What a mess... Thanks for bisecting. I fixed this by pushing part of a branch which I was intending to start to

Re: [cmake-developers] Adding Swift support to CMake

Brad King wrote: On 07/02/2015 07:54 PM, Eric Wing wrote: Thank you Brad. When you are ready, let me know how I can help next. I have basic support with the Xcode generator done. Please try out this commit: Add rudimentary support for the Apple Swift language with Xcode

Re: [cmake-developers] [PATCH] Macro generation for relaxed constexpr

Jean-Michaël Celerier wrote: I think there should be a test for the different allowed contexts of the ${prefix_arg}_RELAXED_CONSTEXPR and ${prefix_arg}_CONSTEXPR macros. Could you extend Tests/Module/WriteCompilerDetectionHeader with a test for that? For sure, I'll do this asap.

Re: [cmake-developers] [PATCH] Macro generation for relaxed constexpr

Jean-Michaël Celerier wrote: Hello, At the ned of this mail is a patch that adds generation of a macro for the relaxed (c++14) constexpr in WriteCompilerDetectionHeader. Thanks for working on this. I have some thoughts for archival purposes on the mailing list. These aren't things you

Re: [cmake-developers] [PATCH] Macro generation for relaxed constexpr

Stephen Kelly wrote: * A method marked constexpr will fail to compile with a compiler which does not support relaxed constexpr if the method uses language which requires relaxed mode (such as a for loop), even if the method is evaluated in a non- constant expression. I tested GCC and Clang

Re: [cmake-developers] Adding Swift support to CMake

Brad King wrote: This seems somehow wrong. Naming it based on some state 'right now' doesn't seem future proof. The 'MSVC' compiler id is not called 'Microsoft', the 'QCC' compiler id is not called 'QNX', 'XL' is not called 'IBM'. The PGI compiler id is PGI. The PathScale compiler id is

Re: [cmake-developers] New policy to address rdynamic

Chuck Atkins wrote: I've implemented a new policy, CMP0065, to restrict the addition of CMAKE_SHARED_LIBRARY_LINK_LANG_FLAGS to executables to only when the ENABLE_EXPORTS target property is set. This should allow us to preserve backwards compatibility in the places it breaks existing

Re: [cmake-developers] refactor-progress topic regressed Makefile progress

On Mon, Aug 31, 2015 at 4:42 PM, Brad King wrote: > During the actual build I get no progress output either. > The problem bisects to: > > cmGlobalUnixMakefileGenerator3: Implement progress in terms of cmState. >

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

Raphael Kubo da Costa wrote: > Adjust the GCC feature detection code to only consider C11 support to > exist on GCC >= 4.9. If you do that you must remove the definition of CMAKE_CXX11_STANDARD_COMPILE_OPTION for GNU < 4.8.1 too. IOW, this patch is not correct, and should not be merged.

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

Michael Scott wrote: > Hi, > > I'm planning on having a look at the CMake issue "Allow ALIAS of > IMPORTED targets", 0015569. After reading the thread between yourself > and Marc, I wanted to ask a couple of things before I start going > further with it. Thanks for working on this. > The

Re: [cmake-developers] Allow ALIAS of IMPORTED targets

Tamás Kenéz wrote: >> For example, if an ALIAS can be IMPORTED, does it makes sense that it can > be >> exported with export() and install(EXPORT)? > > Yes: couple of months ago I was adding install(EXPORT) to an existing > CMakeList. The name of the library target which I had to export was not

[cmake-developers] xcode7-defaults-to-c11 topic

Hi Gregor, Thanks for working on this topic. As GNU 6 defaults to C++14, and clang will probably follow suit, I think it is better to determine the default dialect automatically instead of maintaining numbers like that in Modules/. I have merged a Konsole output compute-default-dialect to next

Re: [cmake-developers] compute-default-dialect topic

Brad King wrote: > The default dialect computed with the compiler id may not be the > same as the effective default dialect when CMAKE_CXX_FLAGS is > considered. One may build with -std=c++11, for example, thus > making the dialect used for compilation different than the raw > compiler default

Re: [cmake-developers] C|CXX Standards Handling

Brad King wrote: > On 09/16/2015 03:56 AM, Daniel Wirtz wrote: >> Basically, CMake silently continues to configure past any >> set(CMAKE_C_STANDARD ) command even if CMake does >> not have any information on the necessary flags for the current compiler. > > For reference, this was discussed

Re: [cmake-developers] compute-default-dialect topic

Brad King wrote: > On 09/16/2015 02:22 PM, Stephen Kelly wrote: >>> The default dialect computed with the compiler id may not be the >>> same as the effective default dialect when CMAKE_CXX_FLAGS is >>> considered. >> >> I pushed another fixup which

Re: [cmake-developers] use-generator-target topic regressed buildsystem properties

Brad King wrote: > Steve, > > The topic merged here: > > Merge topic 'use-generator-target' > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e5953e9 > > regressed handling of the buildsystem-aware properties. > I fixed some of the problems and added test cases. Thanks for those! >

Re: [cmake-developers] Listing all targets

Brad King wrote: > On 09/14/2015 11:46 AM, David Cole wrote: >> (1) I see how I can easily move "COMPONENTS" from >> cmGetCMakePropertyCommand::InitialPass to cmState::GetGlobalProperty >> because I can access the global generator from cmState as well... > > Yes. I assume you're thinking of

Re: [cmake-developers] [PATCH] Features: Only enable C11 support on GCC >= 4.9.

Raphael Kubo da Costa wrote: > Stephen Kelly <steve...@gmail.com> writes: > >> Raphael Kubo da Costa wrote: >> >>> Adjust the GCC feature detection code to only consider C11 support to >>> exist on GCC >= 4.9. >&g

Re: [cmake-developers] CXX_STANDARD and linking

Brad King wrote: > On 09/28/2015 03:55 AM, CHEVRIER, Marc wrote: >> Anyway, the main problem is the fact that, currently, C++ standard >> handling is not usable on Solaris. Do have any plan to fix this problem >> anytime soon? >> >> On 25/09/15 17:24, "Brad King" wrote: >>> Compiling with a

Re: [cmake-developers] CXX_STANDARD and linking

Brad King wrote: > On 09/28/2015 03:20 PM, Brad King wrote: >> for now we should look at turning off all language standard and >> compile feature support for SolarisStudio when not hosted on Linux. > > Done here: > > Features: Disable support for Oracle SolarisStudio on non-Linux >

Re: [cmake-developers] Importing platform SDK libraries without a full path

Brad King writes: > >> Actually I think this can and should be done for INTERFACE libraries > >> even without IMPORTED_LIBNAME. I'll look at factoring this part out > >> into a preceding commit. > > > > Cool, I think reviewing that separately would be preferable. > > > > I'm

Re: [cmake-developers] Help with diagnosing dashboard failure

Brad King wrote: > On 09/22/2015 05:03 PM, Stephen Kelly wrote: >> 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 t

Re: [cmake-developers] Help with diagnosing dashboard failure

Brad King wrote: > On 09/23/2015 03:13 PM, Stephen Kelly wrote: >> The end result of the current fix-max-path-initialization branch is the >> same as it was then. > > Okay. I can reproduce it with the current topic (ba7f7067..16354083). > Wit

<    6   7   8   9   10   11   12   >