Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

2018-08-24 Thread Stephen Kelly
On 24/08/18 02:32, David Blaikie wrote: On Tue, Jul 24, 2018 at 3:20 PM Stephen Kelly <mailto:steve...@gmail.com>> wrote: David Blaikie wrote: > (just CC'ing you Richard in case you want to read my ramblings/spot any > inaccuracies, etc) > > Excu

Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

2018-08-06 Thread Stephen Kelly
Stephen Kelly wrote: >> The build.sh script shows the commands required to build it (though I >> haven't checked the exact fmodule-file dependencies to check that they're >> all necessary, etc) - and with current Clang top-of-tree it does build >> and run the example dinn

Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

2018-07-24 Thread Stephen Kelly
David Blaikie wrote: > (just CC'ing you Richard in case you want to read my ramblings/spot any > inaccuracies, etc) > > Excuse the delay - coming back to this a bit now. Though the varying > opinions on what modules will take to integrate with build system still > weighs on me a bit Can you

Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

2018-05-15 Thread Stephen Kelly
David Blaikie wrote: >> Nope, scratch that ^ I had thought that was the case, but talking more >> with Richard Smith it seems there's an expectation that modules will be >> somewhere between header and library granularity (obviously some small >> libraries today have one or only a few headers,

Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

2018-05-15 Thread Stephen Kelly
Brad King wrote: > On 05/07/2018 12:01 PM, Stephen Kelly wrote: >> Hopefully Brad or someone else can provide other input from research >> already done. > > I'm not particularly familiar with what compiler writers or the modules > standard specification expects build sys

Re: [cmake-developers] Experiments in CMake support for Clang (header & standard) modules

2018-05-07 Thread Stephen Kelly
I think this discussion is more suited to the cmake-developers mailing list. Moving there. Hopefully Brad or someone else can provide other input from research already done. On 05/07/2018 12:49 AM, David Blaikie wrote: > >> The basic commands required are: >> >>   clang++ -fmodules -xc++

[cmake-developers] Embracing Modern CMake Video and Slides

2017-11-05 Thread Stephen Kelly
Hi, I know I'm not active here at the moment, but I thought this post might be interesting for some here: https://steveire.wordpress.com/2017/11/05/embracing-modern-cmake/ Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] Question about ALIAS targets

2017-06-05 Thread Stephen Kelly
Brad King wrote: > Steve, is there any reason for the restriction other than not implementing > more use cases up front? There may be more information in the mailing list archives, but as far as I remember, yes - we wanted to be conservative because we didn't know more use-cases. Additionally,

Re: [cmake-developers] Question about ALIAS targets

2017-06-05 Thread Stephen Kelly
David Cole via cmake-developers wrote: > Is there a good reason why this error must be an error? > > CMake Error at CMakeLists.txt:23 (add_library): > add_library cannot create ALIAS target "MyProj::gtest" because > target "OtherProj::googletest" is IMPORTED. > > The line of

Re: [cmake-developers] [Discussion] Add python support for CMakeLists

2017-01-16 Thread Stephen Kelly
Florent Castelli wrote: > Well, CMake scripts can be written in a somewhat declarative form now. > What prevents this now is that a lot of people use indirections > everywhere. For example: add_library(foo STATIC ${SRCS}) If it was a plain > list, any decent IDE would be able to parse this and

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

2017-01-05 Thread Stephen Kelly
Craig Scott wrote: >> if you use add_subdirectory with top-level projects which don't >> explicitly do something like that, you're getting undefined , and >> generally unexpected behavior in many ways. > > This seems at odds with the CMake documentation for > cmake_minimum_required(). That

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

2017-01-03 Thread Stephen Kelly
René J.V. Bertin wrote: > On Tuesday January 03 2017 11:41:29 Robert Maynard wrote: > >> It is the responsibility of the project to understand what components >> of CMake they require, and correctly specify a cmake_minimum required >> that satisfies all those requirements. In this case to use

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

2017-01-03 Thread Stephen Kelly
René J.V. Bertin wrote: > The > issue was a project that requested an earlier CMake version > (2.8.something) further down. There should be no 'further down'. There should be exactly one use of cmake_minimum_required per buildsystem. If you are hitting this issue because you are cloning

Re: [cmake-developers] cm(Generator)Target::IsFrameworkOnApple

2016-11-17 Thread Stephen Kelly
Gregor Jasny via cmake-developers wrote: > Hello, > > it looks like that during Generator Target refactoring the > cm(Generator)Target::IsFrameworkOnApple and similar got duplicated. Is > there a reason for this or could the GeneratorTarget simply query the > Target? Hi Gregor, The intention

Re: [cmake-developers] Add property to get all linked libraries including transitive ones

2016-11-06 Thread Stephen Kelly
Brad King wrote: > On 11/04/2016 09:52 AM, maikel van den Hurk wrote: >> What about doing what was targeted with this bug: >> https://cmake.org/Bug/view.php?id=12435? > > That issue is now tracked here: > > https://gitlab.kitware.com/cmake/cmake/issues/12435 > > I've just added some notes to

Re: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065

2016-10-06 Thread Stephen Kelly
Brad King wrote: out of place in cmLocalGenerator. If it were returned from cli.GetItems, >>> >>> Yes, it could be moved. >> >> Ok. I might look into that. > > It looks like OutputLinkLibraries currently puts the flag in the > linkLibs (which goes to the placeholder) but it > would

Re: [cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065

2016-10-06 Thread Stephen Kelly
Brad King wrote: > The variable name refers to flags needed when linking an executable *to* > shared libraries. It is a terrible name that has been around since the > earliest days. One could rename the variable in our own platform files > but would have to also honor the old name just in case.

[cmake-developers] CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS and CMP0065

2016-10-06 Thread Stephen Kelly
Hi, I have encountered the implementation of CMP0065. As far as I can see, this is the only use of CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS, and it is not used for shared libraries, but for executables. Finding uses of variables like that is hard because they could be composed like "CMAKE_"

Re: [cmake-developers] Generator options per-directory v. global

2016-10-06 Thread Stephen Kelly
Brad King wrote: > On 10/05/2016 06:38 PM, Stephen Kelly wrote: >> The suggestion to use the first cmMakefile for these kinds of definitions >> is a good one >> >> 1) It can be documented that the variable can only be set in the top >> level 2) It is wha

Re: [cmake-developers] Generator options per-directory v. global

2016-10-05 Thread Stephen Kelly
Craig Scott wrote: > I'm coming in half way to this discussion, so apologies if my comments > interspersed below are not so well related to the core topic of > discussion. Hi Craig, Thanks for your input. > Consider the following example which perhaps better shows that this > problem may not

Re: [cmake-developers] [ANNOUNCE] CMake 3.7.0-rc1 now ready for testing!

2016-10-04 Thread Stephen Kelly
Robert Maynard wrote: > * The "CodeLite" generator gained a new "CMAKE_CODELITE_USE_TARGETS" > option to change project creation from projects to targets. Something that I have often noticed (and which causes problems) in my refactoring is that per-directory variable definitions are used when

Re: [cmake-developers] CMake version to build CMake

2016-09-08 Thread Stephen Kelly
Brad King wrote: > On 09/07/2016 06:44 PM, Stephen Kelly wrote: >> ALIAS targets were introduced in CMake 2.8.12 (released August 2013). >> >> What do you think of updating the requirement to that or higher? > > Fine with me. It really only matters on pla

[cmake-developers] CMake version to build CMake

2016-09-07 Thread Stephen Kelly
Hi, Currently CMake requires a minimum of CMake 2.8.4 to build. I was reviewing the cmake-server work from Tobias starting with the libuv integration, and I think CMake might benefit from using ALIAS targets in its own build. ALIAS targets were introduced in CMake 2.8.12 (released August

Re: [cmake-developers] Developer tasks - Refactoring

2016-09-07 Thread Stephen Kelly
Daniel Pfeifer wrote: > On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly > <steve...@gmail.com> wrote: >> 3) Compute cmGeneratorTarget state non-lazily in its constructor. >> * Historically target state for generators was computed lazily because it >> might need

Re: [cmake-developers] cmake -E capabilities [attempt 2]

2016-08-02 Thread Stephen Kelly
Tobias Hunger wrote: > Hi Stephen, > > thanks for taking the time to do such a thorough review! Actually my review wasn't thorough at all. I didn't try to review it further. The NewFactory methods in your patch don't return a new'd object, but instead return static locals. The regular

Re: [cmake-developers] cmake -E capabilities [attempt 2]

2016-07-26 Thread Stephen Kelly
Tobias Hunger wrote: > Did anyone find some time for a review yet? Hi Tobias, I had a look through this this evening. Thanks for working on this. The commit adding the functionality at the end looks much better after the extra generator refactoring. Here are some review notes: * That

Re: [cmake-developers] Autogen subdirectories patches

2016-07-26 Thread Stephen Kelly
Sebastian Holtermann wrote: >> It might be better to just use a NULL sentinel at the end of the array. >> If not, the extra spaces here should go away. > > I have changed that to use a NULL sentinel. > std::array would be the best solution IMO but it is not allowed, is it? You could use

Re: [cmake-developers] cmake -E capabilities

2016-07-04 Thread Stephen Kelly
Tobias Hunger wrote: > On So, 2016-07-03 at 12:33 +0200, Stephen Kelly wrote: >> Tobias Hunger wrote: >> >> > Either we should have multiConfig return a list of configuration names >> > that will be generated or I do not see any need to have the information

Re: [cmake-developers] cmake -E capabilities

2016-07-03 Thread Stephen Kelly
Tobias Hunger wrote: > Hello CMake Developers! > > As laid out in the last mail thread about daemon-mode in CMake (for your > reference: > http://public.kitware.com/pipermail/cmake-developers/2016-June/028777 > .html ), Stephen and me agreed that we needed a way for IDEs to figure out > which

Re: [cmake-developers] cmake -E capabilities

2016-07-03 Thread Stephen Kelly
Tobias Hunger wrote: > Either we should have multiConfig return a list of configuration names > that will be generated or I do not see any need to have the information in > the first place. I think when using qmake with QtCreator, the user can choose the configuration at build time by selecting

Re: [cmake-developers] cmake -E capabilities

2016-07-03 Thread Stephen Kelly
Brad King wrote: > On 07/01/2016 05:11 AM, Tobias Hunger wrote: >>> For "multiconfig", there is the cmGlobalGenerator::IsMultiConfig method. >> I do not see why this information is need to set up a cmake project. I >> need two directories and a generator. Do I need to know what the >> generator

Re: [cmake-developers] daemon-mode meeting last Tuesday

2016-06-28 Thread Stephen Kelly
Tobias Hunger wrote: > Hello CMake Developers, > > Stephen Kelly and me met last Tuesday to talk about the daemon-mode patch > we both have been working on. It was a very productive meeting: We managed > to resolve almost all the differences of opinion we had. Thanks Tobias

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

2016-06-22 Thread Stephen Kelly
Brad King wrote: > I logged out and logged back in and > then everything gets the proper PATH. > > Then I un-installed again and had to logout/login again to get the > PATH updated for programs launched through shortcuts. Hmm, I didn't do any logging out or in. Maybe that was the cause.

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

2016-06-20 Thread Stephen Kelly
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

2016-06-20 Thread Stephen Kelly
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

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

2016-06-18 Thread Stephen Kelly
Hi, the outcome of https://cmake.org/Bug/view.php?id=15578 seems to be https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=78ec0461 a DIRECTORY property VS_STARTUP_PROJECT which sets the start up project in Visual Studio. I tried it in the 3.6 RC and it works fine if I set the

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

2016-06-18 Thread Stephen Kelly
Hi, 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). Then, in my 'Visual Studio 14 2015 64 bit command prompt', the cmake executable was no longer found. I think the difference is that the 64 bit

Re: [cmake-developers] daemon-mode: Project structure

2016-06-13 Thread Stephen Kelly
Tobias Hunger wrote: >> * Designing a protocol like this is hard (and not fast) > > We have been discussing this for about two years now. That's a misleading thing to say. Time since an effort or discussion started has never been a guideline for when something is ready for CMake master. > I

Re: [cmake-developers] Review request: extract-cmMessenger branch

2016-06-13 Thread Stephen Kelly
On 06/13/2016 04:22 PM, Brad King wrote: > On 06/11/2016 08:14 AM, Stephen Kelly wrote: >> Thanks for your thorough review! I think I've fixed the errors I >> introduced while rebasing now. >> >> I'm not completely certain that the gymnastics I do with the >>

Re: [cmake-developers] daemon-mode: Project structure

2016-06-11 Thread Stephen Kelly
On 06/10/2016 11:35 PM, Tobias Hunger wrote: > > > Part of the design of the daemon is that messages that it sends can be > > 'spontaneous' - it watches for filesystem changes and can tell > clients to > > re-read the buildsystem information. > > That is currently not done or needed, but can be

Re: [cmake-developers] Review request: extract-cmMessenger branch

2016-06-11 Thread Stephen Kelly
On 06/10/2016 10:07 PM, Daniel Pfeifer wrote: > On Fri, Jun 10, 2016 at 8:17 PM, Stephen Kelly <steve...@gmail.com> wrote: >> However, that's not a problem when messages are delivered through the >> daemon, so I suggest that >> >> https://github.com/stevei

Re: [cmake-developers] daemon-mode: Project structure

2016-06-10 Thread Stephen Kelly
Tobias Hunger wrote: > Hello everybody, > > I made some progress with extracting project structure from cmake via the > daemon-mode. I am rather happy with the information and would love to get > some feedback from other interested parties. > > Here is the format that is currently reported

Re: [cmake-developers] cmCacheManager related changes

2016-06-10 Thread Stephen Kelly
Brad King wrote: > cmState: Expose list of properties of values in the cache > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63c0e92c The way these classes are designed, cmState is intended to be the way to access state which generally does not change during a CMake configure run in a

Re: [cmake-developers] Review request: extract-cmMessenger branch

2016-06-10 Thread Stephen Kelly
Tobias Hunger wrote: > Forcing messages into one consistent format will be a pain, agreed, but > continuing to add messages in whatever form the developer likes at the > time of writing the code is even worse. CMake has a lot of different error > message styles! This is something my branch

Re: [cmake-developers] Review request: extract-cmMessenger branch

2016-06-09 Thread Stephen Kelly
On 06/09/2016 09:49 AM, Daniel Pfeifer wrote: > On Thu, Jan 28, 2016 at 10:42 PM, Stephen Kelly <steve...@gmail.com> wrote: >> Hi, >> >> I have pushed a extract-cmMessenger branch to my clone: >> >> https://github.com/steveire/CMake/commits/extract-cm

Re: [cmake-developers] CMake daemon-mode

2016-06-08 Thread Stephen Kelly
On 06/07/2016 11:42 AM, Daniel Pfeifer wrote: > On Mon, Jun 6, 2016 at 7:24 PM, Brad King wrote: >> On 06/06/2016 11:39 AM, Tobias Hunger wrote: >> >>> A big chunk of Stephen's work has not even landed in my branch yet. Since >>> cmake >>> reformated all the source in the

Re: [cmake-developers] Developer tasks - Refactoring

2016-06-06 Thread Stephen Kelly
On 06/06/2016 11:14 PM, Daniel Pfeifer wrote: > Here is what I found. > > * SetLinkScriptShell is called from two places: > cmMakefileExecutableTargetGenerator::WriteExecutableRule and > cmMakefileLibraryTargetGenerator::WriteLibraryRules. > * We can instantiate a cmOutputConverter in those places

Re: [cmake-developers] Developer tasks - Refactoring

2016-06-05 Thread Stephen Kelly
On 05/19/2016 11:27 PM, Daniel Pfeifer wrote: > On Wed, Feb 10, 2016 at 12:12 AM, Stephen Kelly <steve...@gmail.com> wrote: >> 1) Make cmLocalGenerator not inherit cmOutputConverter >> * Change enums like cmLocalGenerator::START_OUTPUT with sed. See >> >>htt

Re: [cmake-developers] Developer tasks - Refactoring

2016-06-05 Thread Stephen Kelly
On 05/20/2016 12:06 AM, Daniel Pfeifer wrote: > On Thu, May 19, 2016 at 11:18 PM Daniel Pfeifer > <dan...@pfeifer-mail.de <mailto:dan...@pfeifer-mail.de>> wrote: > > On Wed, Feb 10, 2016 at 12:15 AM Stephen Kelly <steve...@gmail.com > <mailto:steve...@gmail

Re: [cmake-developers] CMake daemon for user tools

2016-03-28 Thread Stephen Kelly
On 03/25/2016 09:25 AM, Tobias Hunger wrote: > I am personally rather unsure about how to proceed. I can help make > this branch production/merge ready, but I do not want to maintain it > indefinitely after it is merged. It touches to many CMake internals > for me to be comfortable hacking on that

Re: [cmake-developers] Listing all targets

2016-03-13 Thread Stephen Kelly
Clifford Yapp wrote: > On Mon, Sep 14, 2015 at 1:47 PM, Stephen Kelly > <steve...@gmail.com> wrote: >> Making the target names available through properties via cmState is also >> trivial after targets become first-class parts of cmState >> (cmState::Target like cmSta

Re: [cmake-developers] CMakeFindDependencyMacro limitations

2016-03-05 Thread Stephen Kelly
Roger Leigh wrote: > On 24/02/2016 22:49, Roger Leigh wrote: >> I've attached a patch for a very simple modification to find_dependency. >> I'm not proposing that it be merged, it's just a suggestion for >> further discussion. I've tested it with my own packages with multiple >>

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

2016-02-22 Thread Stephen Kelly
Alexander Neundorf wrote: > On Monday, February 22, 2016 22:30:42 Stephen Kelly wrote: >> Jean-Michaël Celerier wrote: >> > There is also https://www.cevelop.com/ which is an Eclipse derivative, >> > they may be interested ? >> >> I went all h

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

2016-02-22 Thread Stephen Kelly
Jean-Michaël Celerier wrote: > There is also https://www.cevelop.com/ which is an Eclipse derivative, > they may be interested ? I went all hipster reach-out.io and tweeted at them. :) -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

2016-02-19 Thread Stephen Kelly
Alexander Neundorf wrote: > On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote: >> On 02/15/2016 07:24 PM, Tobias Hunger wrote: >> > Hi Dominik, >> > >> > Am 15.02.2016 19:01 schrieb "Dominik Haumann" >> > <dhaum...@kde.org

Re: [cmake-developers] CMake Daemon blog

2016-02-17 Thread Stephen Kelly
Taylor Braun-Jones wrote: > On Sat, Jan 30, 2016 at 2:06 AM, Stephen Kelly > <steve...@gmail.com> wrote: >> I've just pushed the daemon code here: >> >> https://github.com/steveire/cmake/tree/cmake-daemon >> >> The Kate plugin should soon appear here I

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

2016-02-17 Thread Stephen Kelly
On 02/15/2016 07:24 PM, Tobias Hunger wrote: > > Hi Dominik, > > Am 15.02.2016 19:01 schrieb "Dominik Haumann" >: > > 1. Wouldn't it make sense you have a developer sprint ASAP for this? > > I'd be in, but I do not have the time to organize one. I could

Re: [cmake-developers] CMake Daemon

2016-02-10 Thread Stephen Kelly
Tobias Hunger wrote: > Hi Stephen, > > stupid question: How do I run the server-mode autotests? > > I just implemented a unified way to do progress reporting and want to > make sure that did not break too much. Running > Tests/Server/daemon-test.py manually works, but how do I run all those >

[cmake-developers] Developer tasks - Daemon mode

2016-02-09 Thread Stephen Kelly
The Daemon mode for CMake is online here: https://github.com/steveire/CMake/tree/cmake-daemon The commit messages and some of the commits contain indications of things that need to be done before such a mode could be introduced into CMake, such as writing a new failsafe parser and

Re: [cmake-developers] CMake Daemon

2016-02-09 Thread Stephen Kelly
Stephen Kelly wrote: > Tamás Kenéz wrote: > >> That's great and really does open a new world for IDEs! > > Thanks! Let's see if the interest grows. > > I've just pushed the daemon code here: > > https://github.com/steveire/cmake/tree/cmake-daemon Tobias mad

Re: [cmake-developers] CMake Daemon blog

2016-02-09 Thread Stephen Kelly
Stephen Kelly wrote: > Hi, > > I just made a blog and video about the advanced features and possibilities > that a daemon mode for CMake can bring: > > https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ > The lack of response on the list to

[cmake-developers] Developer tasks - Refactoring

2016-02-09 Thread Stephen Kelly
In order to make it possible to implement fully featured user tools like the cmake daemon https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ ... and to make it possible to use multiple toolchains at once

Re: [cmake-developers] CMake 3.5 generation time

2016-02-06 Thread Stephen Kelly
Bartosz Kosiorek wrote: > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0c97d32f The relevant part of that patch (from the point of view of separating configure time code from generate time code) is the removal of the use of TotalTargets at generate time. Mappings could be re-introduced

Re: [cmake-developers] Review request: extract-cmMessenger branch

2016-02-06 Thread Stephen Kelly
Michael Scott wrote: >> Yes. Did you have a close look at the commits? I'm not really sure they >> are correct, and I wonder if you have any thoughts on the first one which >> discusses interface? > I went back and had a closer look at the major changes. I think on the > whole the cmMessenger

Re: [cmake-developers] Namespaces

2016-01-30 Thread Stephen Kelly
Pau Garcia i Quiles wrote: > But that does not work unless I juggle with add_library(... IMPORTED) or I > use Hunter or alike. I did something like that a few months ago: https://github.com/Ableton/aqt-cassowary/blob/master/src/CMakeLists.txt However, that's not a pattern which scales I

Re: [cmake-developers] Review request: extract-cmMessenger branch

2016-01-30 Thread Stephen Kelly
Michael Scott wrote: >> * Make it possible to make add first-class handling of messages about >> missing packages (for example) to cmake-gui by making methods on >> cmMessenger virtual and subclassing > > This sounds like a good idea and makes a lot of sense. > > While working on the message

Re: [cmake-developers] Namespaces

2016-01-28 Thread Stephen Kelly
Pau Garcia i Quiles wrote: > CMake should wrap every variable defined under the directory added with > add_subdirectory(QtZeroConf NAMESPACE QTZEROCONF) So, CMake needs to first determine what variables are used in the QtZeroConf directory (presumably without executing the cmake code there) and

Re: [cmake-developers] Namespaces

2016-01-28 Thread Stephen Kelly
Pau Garcia i Quiles wrote: > On Thu, Jan 28, 2016 at 8:21 PM, Stephen Kelly > <steve...@gmail.com> wrote: > > > Pau Garcia i Quiles wrote: >> >> > CMake should wrap every variable defined under the directory added with >> > add_subdirectory(QtZeroCon

[cmake-developers] Review request: extract-cmMessenger branch

2016-01-28 Thread Stephen Kelly
Hi, I have pushed a extract-cmMessenger branch to my clone: https://github.com/steveire/CMake/commits/extract-cmMessenger The motivations are: * Decrease responsibilities of the cmake class. CMake uses too few classes for too many things * Make it possible to make add first-class handling of

Re: [cmake-developers] Namespaces

2016-01-28 Thread Stephen Kelly
Pau Garcia i Quiles wrote: > add_subdirectory(pugixml/scripts) > add_subdirectory(QtZeroConf) > add_subdirectory(QtDropBox) > add_subdirectory(websocketpp) > > This is an easy way to work with third-party dependences. Unfortunately this is 'easy, obvious and wrong'. > My problem comes from the

Re: [cmake-developers] Anyone going to FOSDEM?

2016-01-25 Thread Stephen Kelly
s, an advanced user, but I > will go to FOSDEM next year. ;-) > At least Stephen Kelly [2] will be there, too. Yep. Maybe we could arrange to meet in the Sunday evening. I leave on the Monday. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check th

[cmake-developers] CMake Daemon blog

2016-01-24 Thread Stephen Kelly
Hi, I just made a blog and video about the advanced features and possibilities that a daemon mode for CMake can bring: https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ I'll make the code available by the end of the week. I still want to clean it up a little bit first

Re: [cmake-developers] EXPORT dependency handling

2016-01-20 Thread Stephen Kelly
Roger Leigh wrote: >add_library(OME::BioFormats INTERFACE IMPORTED) >set_target_properties(OME::BioFormats PROPERTIES > INTERFACE_LINK_LIBRARIES ome-bioformats) > > It's the last two lines. Internally, the target name is ome-bioformats, > but I actually want it to be OME::BioFormats as

Re: [cmake-developers] CMake daemon for user tools

2016-01-20 Thread Stephen Kelly
Milian Wolff wrote: >> I'm concerned that the memory usage of a daemon implementing the proposed >> capabilities may be too large to be practical (at least without a major >> redesign of certain structures that tend to duplicate substrings, or >> some kind of out-of-core approach). > > This

Re: [cmake-developers] [PATCH] FindPNG: Create an imported PNG::PNG target

2016-01-20 Thread Stephen Kelly
rle...@codelibre.net wrote: >>> + INTERFACE_LIBRARIES "${PNG_LIBRARIES}") >> >> Shouldn't this refer to zlib instead of png libraries again? > > I would have expected something like > > set_target_properties(PNG::PNG PROPERTIES INTERFACE_LINK_LIBRARIES > ZLIB::ZLIB) For reference, this is

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

2016-01-20 Thread Stephen Kelly
Michael Scott wrote: > If there are any problems with the proposed changes let me know. Hi Michael, Thanks for working on this topic over such a long time period to get it right. I closed http://public.kitware.com/Bug/view.php?id=15677 and

Re: [cmake-developers] cmake daemon mode protocol

2016-01-16 Thread Stephen Kelly
Stephen Kelly wrote: > I recommend focussing on the tasks in my OP: > > http://thread.gmane.org/gmane.comp.lib.qt.creator/11794 To be more clear: The goal I have is to enable debugging, introspection of the buildsystem and the state during execution, code completion etc. Your g

Re: [cmake-developers] cmake daemon mode protocol

2016-01-16 Thread Stephen Kelly
Tobias Hunger wrote: >> For this case, I suggest that if the user tries to 'open the source >> directory', you would use QTemporaryDir to build in a temporary location > and >> run the daemon there. I believe clion does something equivalent to that. >> Is that viable? I suppose you are suggesting

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

2016-01-14 Thread Stephen Kelly
Brad King wrote: > I think the responses in this thread have indicated there is interest > in working toward the full daemon approach. Perhaps discussion should > now proceed on the daemon protocol design over in the thread Tobias > started on cmake-developers: > > cmake daemon mode protocol >

Re: [cmake-developers] cmake daemon mode protocol

2016-01-14 Thread Stephen Kelly
Tobias Hunger wrote: > Hi Stephen, > > I have successfully build and run your cmake server mode changes and > the python client script does work as advertised. Thanks for doing that! > I do have a couple of remarks about it. This is more intended as a > starting point for discussion as a real

Re: [cmake-developers] CMake alternative language

2016-01-14 Thread Stephen Kelly
Charles Huet wrote: > When the configure step takes > about 30 seconds, and all you can do is use MESSAGE() to find what > happens, this is no walk in the park. A real debugger would do a world of > good to CMake. This is one of the things that I address with the daemon work - a 'recording' is

Re: [cmake-developers] CMake daemon for user tools

2016-01-12 Thread Stephen Kelly
Tobias Hunger wrote: > So could we please get a *documented* way that an IDE can *rely on to > be available* that provides basic information on a > project/configuration: > > * Source directory, build directory > * Files that belong to the project (sources, headers, custom cmake > modules,

Re: [cmake-developers] CMake daemon for user tools

2016-01-12 Thread Stephen Kelly
Brad King wrote: > The proposed daemon could help IDEs integrate with the CMake language > without re-implementing it, but we may not need such heavy infrastructure > for IDEs just to list targets and sources and allow users to edit them. Do you agree that that's an orthogonal use-case (add file

Re: [cmake-developers] [Qt-creator] CMake daemon for user tools

2016-01-12 Thread Stephen Kelly
Brad King wrote: >> Alexander goes back to the generator approach we discussed a year ago >> and explicitly says he won't work on that, so nothing will happen >> there. > > The generate-json-description approach remains a valid alternative. > Aleix's work on it got pretty far before Stephen

[cmake-developers] CMake daemon for user tools

2016-01-10 Thread Stephen Kelly
Hello, I've been working on adding a daemon mode for cmake to provide information to user tools - such as IDEs - about the buildsystem. Following the discussion about providing metadata for IDEs to consume I proposed creating a long-running process which would provide a protocol to access

Re: [cmake-developers] Using CMake as a library from Python

2016-01-03 Thread Stephen Kelly
Charles Huet wrote: > * cmCacheManager::AddCacheEntry was made public, as cmake::Configure > cannot be used from python (it check for the existence of a CMakeLists.txt > file, which does not exist in this scenario) and the cache variables it > sets seem to be necessary. Because of the above, I

Re: [cmake-developers] CMakeFindDependencyMacro limitations

2015-12-24 Thread Stephen Kelly
Roger Leigh wrote: > On 21/12/2015 15:07, Stephen Kelly wrote: >> Roger Leigh wrote: >>> I can understand why REQUIRED and related >>> arguments are omitted--that is why find_dependency exists--but I'd quite >>> like to be able to specify COMPONE

Re: [cmake-developers] CMakeFindDependencyMacro limitations

2015-12-21 Thread Stephen Kelly
Roger Leigh wrote: > I've run into a few limitations in find_dependency. I'm not sure if > these are by design or could be fixed, so this is really a request for > further explanation or design rationale. > > The first issue is this: > >if (NOT ${dep}_FOUND) > > This seems to be making

Re: [cmake-developers] ARMCC toolchain support

2015-10-27 Thread Stephen Kelly
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

2015-10-27 Thread Stephen Kelly
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

2015-10-27 Thread Stephen Kelly
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)

[cmake-developers] Adding LFS define to build command line?

2015-10-27 Thread Stephen Kelly
Hi, The build on AIX at https://open.cdash.org/viewBuildError.php?buildid=4072769 failed. The failure was fixed on the minor-cleanups branch. Looking at the error, it occurred while compiling the cmGeneratorExpressionNode.cxx file because at some points in the translation unit, a certain

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

2015-10-27 Thread Stephen Kelly
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] Adding LFS define to build command line?

2015-10-27 Thread Stephen Kelly
Brad King wrote: > On 10/27/2015 04:06 PM, Stephen Kelly wrote: >> Would it be possible to define the necessary preprocessor defines on the >> command line instead of relying on include order or headers? That would >> make this kind of thing not happen afaict. > > T

Re: [cmake-developers] CMakeForceCompiler

2015-10-19 Thread Stephen Kelly
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] Generating buildsystem metadata from CMake

2015-10-13 Thread Stephen Kelly
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

2015-10-13 Thread Stephen Kelly
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

2015-10-13 Thread Stephen Kelly
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] ITK NIfTI broken Oct 6

2015-10-12 Thread Stephen Kelly
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

2015-10-12 Thread Stephen Kelly
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

  1   2   3   4   5   6   7   8   9   10   >