Re: [cmake-developers] [CMake] Why does INTERFACE type targets only support whitelisted properties?

[Taylor Braun-Jones]

On Fri, Jan 8, 2016 at 9:12 AM, Nils Gladitz  wrote:

>
>
> On 01/08/2016 02:50 PM, Yves Frederix wrote:
>
>> You are explicitly mentioning 'setting' of a property. IMHO there is a
>> big difference between setting and getting a property. If
>> white/blacklisting is enforced during setting only, wouldn't this be
>> sufficient? This would make it possible to simply access all
>> properties that are automatically assigned to the target (which I
>> assume implies that by definition they should make sense?). A
>> non-acceptable property could not have been set and would hence not be
>> found, making it possible to check for its existence in the "standard"
>> way.
>>
>
> The same argument might hold for getting of properties.
> E.g. hypothetically if SOURCE_DIR were not set for INTERFACE properties
> now but was implemented in the future.
>
> A user might e.g. think that a specific property should work because CMake
>>> did not issue any diagnostics and open an issue.
>>> The diagnostic implies that this behavior is by design.
>>>
>>> It also prevents users from using existing properties which currently
>>> don't
>>> have semantics for INTERFACE targets but might be implemented in the
>>> future
>>> (potentially with different semantics than expected by the user).
>>>
>> Ok, this somehow contradicts my above assumption and is somewhat
>> surprising. Wouldn't it make sense to simply not set these properties
>> in the first place if they have incorrect semantics? This way,
>> get_property would not need to care about them and it would anyhow not
>> stop their correct implementation in the future.
>>
>
> I meant existing as in defined for regular build targets not as in
> actually set for interface targets.
> get_property() would return an empty string for those if they weren't
> whitelisted and one might argue that this could suffice.
> On the other hand users often assume that they get a valid value and don't
> actually check.
>
>
>>> I think allowing custom (non cmake defined) properties might be a valid
>>> argument.
>>> These could perhaps also be supported through e.g. user extension of the
>>> whitelist.
>>>
>> I like this idea. With this in place, one would not need to wait for a
>> new CMake release if a valid property were missing from the whitelist
>> or if one wanted to use custom properties.
>>
>> I don't think anything should be changed however unless there are actual
>>> use
>>> cases that aren't supported by the current implementation.
>>>
>> Does this mean that you would have doubts about patches that:
>>   - provide a way for the user to extend the whitelist?
>>   - remove the need for whitelisting in get_property by making CMake
>> only automatically assign sensible target properties?
>>
>
> The issue is less that CMake assigns these properties (I don't know of any
> such case but I haven't checked) and more that users might just expect them
> to be set (which does not provide a diagnostic).
>
> Personally I would not object to either approach as long as there are
> actual use cases.
> Without use cases such changes would be by definition useless.


I have another INTERFACE property use case that is not whitelisted, but
should be: VERSION

Consider library project Foo that uses a header-only project Bar. In
FooConfig.cmake, it is a important to ensure any projects using Foo also
use the exact same version of Bar that Foo was originally built with
(Failure to do so can lead to subtle, hard-to-find bugs like violation of
the one definition rule). Assuming project Bar creates an imported target
"Bar" with a VERSION property set like:

  set_property(TARGET Bar APPEND PROPERTY VERSION 1.2.3)

Then project Foo should be able to have something like:

== CMakeLists.txt ==
...
get_property(FOO_BAR_VERSION TARGET BAR PROPERTY VERSION)
configure_file(FooConfig.cmake.in FooConfig.cmake @ONLY)

== FooConfig.cmake.in ==
...
find_package(Bar "@FOO_BAR_VERSION@" EXACT REQUIRED)

But, alas, this is not currently possible. I'm ambivalent about whether
INTERFACE properties should be whitelisted vs blacklisted vs unrestricted,
but at least this VERSION property seems valid to allow.

Taylor
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Alexander Neundorf]

On Monday, January 11, 2016 15:59:35 Aleix Pol wrote:
...
> 
> Hi Stephen, everyone,
> I've already discussed this in private with you. I think it's a good
> idea and I'd like to make sure we can benefit from this.
> 
> I'm unsure of the feasibility of the project though. 

you maybe remember that my main issue with your patch last year was that it's 
not a "generator", while it does what generators are for.
After talking with Milian a bit several week ago, I understood that an 
important reason why the kdevelop team does not want a generator is that there 
is only one generator per build-tree, i.e. the user has to decide beforehand 
which IDE project files he wants.
With the branch I created on github a few days ago, which I announced here 
too, I changed the way the extra generators are activated: they are not 
activated like the main generators anymore, but can be turned on and off using 
normal cmake cache options, so multiple generators (e.g. the generic json 
generator and let's say the Eclipse generator) can both be turned on, 
initially or later on. I think this should solve this problem.
The work there 
(https://github.com/neundorf/CMake/tree/RefactorExtraGeneratorsExperimental ) 
is not ready for inclusing, but it shows how it can be done and can serve as a 
starting point/inspiration.

Stephens big approach will need some time until it is ready, while such a 
(relatively) simple thing can probably be done within one release cycle (but I 
don't have the time to do it).

I don't know what the others here think about adding your json-approach or 
not.

Alex

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

[Petr Kmoch]

Hi all.

I'd like to voice my opinion as a somewhat advanced CMake user here.

For me, one of the strongest points of CMake is the fact that its project
specification is procedural rather than declarative. In my current job, for
example, we have a significant framework built in CMake which handles a lot
of unique setups we have (which were largely inherited from a previous
inhouse buildsystem). Yes, the end result of our framework is that the
CMakeLists consist mostly of declarative commands from our framework, but
the implementation of these commands is heavily procedural. I am convinced
that if CMake didn't give us the procedural power required to make this
work, we couldn't have adopted it. (I had previously tried emulating bits
of this setup in a more declarative system and failed miserably).

Of course (having written much of this framework I'm talking about above),
I know all too well that a better front-end language would do a world of
good for CMake. I also understand that taking a more declarative approach
could help that, and I'm not opposed to such a change in principle.
However, please take care not to throw the baby out with the bathwater and
nerf the expressiveness of what can be done with CMake (in a procedural
way).

If I understand Brad's suggestion correctly, it would amount to a (possibly
empty) procedural step being used to generate a declarative description of
the buildsystem. This would work well in our scenario, I believe, as long
as that procedural step could be sufficiently modularised on the client
side.

I fully support introducing an alternative input language to CMake and
taking all steps necessary for this to happen, but please do this in a way
which will not restrict what CMake is capable of doing.

Petr

On Fri, Jan 8, 2016 at 5:30 PM, Brad King  wrote:

> Hi Charles,
>
> Thanks for your efforts in exploring this topic.  CMake's current language
> grew incrementally out of something that was not originally intended as a
> programming language.  The cmState refactoring Stephen Kelly has started
> is a huge step toward enabling alternative languages, but there is a long
> way to go.
>
> A few general thoughts:
>
> * One rule we have for CMake is to never expose any public SDK of the C++
>   implementation structures.  We want to be able to rewrite them
> arbitrarily
>   at any time.  Therefore any solution that needs to access the C++
>   structures must be integrated into CMake upstream and expose
> functionality
>   only through other languages or file formats.
>
> * The cmState infrastructure builds on a "snapshot" design with a goal of
>   being able to "fork" configuration/generation temporarily and then revert
>   back, and to be able to re-start configuration from the middle.  These
>   goals may be incompatible with any language whose implementation we do
>   not fully control unless it is allowed to execute only in isolated and
>   independent snippets.  These are not hard goals, but it is a trade-off
>   to keep in mind.  Stephen may be able to elaborate more on the snapshot
>   approach if needed.
>
> * A problem with the current design is that the entire configuration
> process
>   is logically serial making parallel evaluation hard or impossible.  In
>   many cases each add_subdirectory can be processed independently, but this
>   will require semantic changes to allow.
>
> On 01/04/2016 02:41 AM, Charles Huet wrote:
> > I'm trying to be as declarative as possible, because really like how
> readable
> > simple QML programs are, and I think it would be perfect for a
> buildsystem.
>
> Ideally most of the specification (sources, libraries, executables, etc.)
> should be in a pure format that can be evaluated without side effects (e.g.
> declarative or functional).  This rules out both Python and Lua, but the
> specification format does not have to be the main entry point.  There could
> be some imperative configuration step that does system introspection and
> then loads the pure specification and evaluates it as needed for the
> specific
> environment.
>
> If we're going to go through the effort to provide an alternative input
> format,
> I think we should strive for this approach because it will be more
> flexible in
> the long run.  A pure specification format will allow easy loading/saving
> by
> other tools, IDEs, etc., without having to process any imperative logic.
>
> > Actually, I'm directly using the cmMakefile, because I did not want to
> wrap all
> > the commands, and it seemed backwards to me to wrap them.
>
> Yes.  Any alternative format should be processed directly into the
> structures
> used by the generators.  The cmState work has separated the generate-time
> representation quite a bit from the configuration-time
> (cmake-language-specific)
> representation, but I think there is still further work needed to finish
> that.
>
> >> Having said all that, Brad favors Lua I believe, and he favors a
> different
> >> approach 

Re: [cmake-developers] FindwxWidgets.cmake

[Brad King]

On 01/11/2016 01:18 PM, Simon Wells wrote:
> The following code is line 191-201, I have tested without this being set
> on OSX 10.11 using system clang and both self-built and brew installed
> wxwidgets with no problems, Whether its still an issue using gcc on osx
> or some other configuration i am unsure, but is it worth being more
> specific than just If APPLE for this bug-fix/workaround

Thanks.  The only way to get more detail on the problems is to wait for
someone to hit them again.  Meanwhile we can just restore -isystem:

 FindwxWidgets: Drop suppression of -isystem
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4d05f195

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language

[Brad King]

Hi Folks,

I'm replying directly to my previous post in this thread in order to consolidate
responses to related discussion raised in others' responses to it:

 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15383
 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15386
 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15339/focus=15389

General comments:

* There is a lot of code out there in the current CMake language so I do not
  think it is realistic to drop it.  I'm not proposing that this change.

* CMake's procedural/imperative design is good as the main entry point to
  configuration of a project.  It can do system introspection, file generation,
  etc.  I'm not proposing that this change.

* Many projects build elaborate macro/function systems in the CMake language
  in order to end up with a declarative specification listing the actual
  source files, dependencies, and usage requirements.  I'd like to offer
  an alternative to this.

* Integration with IDEs is currently based on one-way generation (VS IDE
  projects, Xcode projects, CodeBlocks, etc.).  Editing the project build
  specification requires editing CMake code directly because IDEs cannot
  easily pierce CMake's procedural/imperative specification:

https://cmake.org/pipermail/cmake-developers/2016-January/027386.html

  I'd like to improve this by *optionally* moving part of the specification
  to a (stateless) declarative format that IDEs can load/edit/save directly.

Specific responses follow.



On 01/11/2016 12:24 PM, Charles Huet wrote:
> I think these goals aim towards a faster configure, and the ability to
> only partly reconfigure, right?

Yes.

> I know I am largely biased by the project I work on, but I do not see how
> parallel evaluation woud be a huge benefit.
[snip]
> And how would that work with CMakeLists that affect their parent scope ?

Evaluation of the imperative language is currently serial for reasons like
this, which is why I said it would take semantic changes to enable parallel
evaluation. This is not the main point of my proposal so I'd rather not
get bogged down in the details of this part of the discussion.

>> Ideally most of the specification (sources, libraries, executables, etc.)
>> should be in a pure format that can be evaluated without side effects (e.g.
>> declarative or functional).
>
> I'm not sure I understand how this could be done without losing a lot of
> what CMake offers, such as copying or generating files.

I'm not proposing dropping the current imperative capabilities.

> I'm leaning towards a declarative approach as it is quite easy to learn
> (since you declare objects, and every C++ programmer I know is familiar
> with those)

Yes.

> It seems you are leaning towards pure functional, but I do not see how
> this would work with the current way CMake handles variables and scope,
> could you elaborate ?

While declarative may get us most of the way, advanced users may wish to
hook in to generation-time evaluation. A clean way to do that would be
to specify a function within the declared values. It would not have to
be in a functional language as long as it has no access to anything other
than the inputs passed to it during evaluation.

I mentioned "functional" mostly as an example of a specification whose
evaluation is free of side effects.

> To clarify, only the following lines should be considered when looking at the 
> POC.
>> myProject=cmake.Project("MyTestProject")
>> myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])]

Yes, this is the kind of stuff that can be in a declarative format.

> It seems you have in mind to write a new CMake language.

No, at most a new specification format that can be used for IDE integration.
If some kind of user-coded function were included in the specification it
should certainly be in an existing language.

> Maybe I should take my POC further

I think implementation even of a POC is premature at this point.  We
should explore the design space further.

> CMake's own buildsystem seems like a good testing ground for this, but
> it is a little too big for a first go, do you know of a small CMake-based
> project that would be better suited ?

Maybe you could find something in our test suite.

> I don't have a clear view of what a pure functional CMake would look like,
> but if you give me some mock code, I could give a try at bringing some pure
> functional language up to the level of my POC and we could use it as a more
> concrete discussion support.

I have no prototype (nor substantial time to spend on design myself) but
I've imagined a declarative format in a well-known syntax (e.g. JSON or one
of the lightweight human-friendly choices).  If generate-time functionality
is needed then code snippets in e.g. Lua could be included.

[cmake-developers] [CMake 0015909]: FindDCMTK.cmake outdated

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15909 
== 
Reported By:dkuegler
Assigned To:
== 
Project:CMake
Issue ID:   15909
Category:   Modules
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-01-11 16:07 EST
Last Modified:  2016-01-11 16:07 EST
== 
Summary:FindDCMTK.cmake outdated
Description: 
The FindDCMTK in CMake is very outdated. It produces errors and all the
libraries and paths have to be set up manually.

The script straight up, does not find DCMTK, even if specifically pointed to the
right path with DCMTK_DIR.

But there is a up-to-date buildscript, that works properly in the CTK toolkit:
https://github.com/commontk/CTK/blob/master/Utilities/CMake/FindDCMTK.cmake

So I would propose to use that file.

Steps to Reproduce: 
install DCMTK
build DCMTK

create a CMakeLists.txt with
set(DCMTK path/to/dcmtk/build/folder)
find_package(DCMTK)

Additional Information: 
tested with Windows 8.1, CMake 3.3, 3.4
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-01-11 16:07 dkuegler   New Issue
==

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Visual Studio 2015 FastLink

[Thomas]

Dear Cmake developers,
as a follow up of this bug
https://cmake.org/Bug/view.php?id=15894

I'm writing to request support for the /Debug:FastLink flag which was
introduced in visual studio 2015 (update 1), and the option to generate
full PDB informations.
http://blogs.msdn.com/b/vcblog/archive/2015/10/16/debug-fastlink-for-vs2015-update-1.aspx

Brad King already setup the correct framework in "next" branch to implement
the /Debug:FastLink and with the proposed patch (last topic in the bug) it
works good.

About the "Generate Full PDB informations" , is a new option that can be
used to re-use pdbs generated with the fastlink flag in a different
computer from the one who did the compilation (it may be useful sometimes).
That option seems to doesn't have a (public) command line switch, instead
it relies on an XML property.

When the user requests "Generate Full PDB informations", the generator
should add
true
in the  section.

What's the best way to set a TARGET or global property which would enable
the switchless XML property in the generator?

Thanks!
Qb
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

[Charles Huet]

Hi,

> * The cmState infrastructure builds on a "snapshot" design with a goal of
  being able to "fork" configuration/generation temporarily and then revert
  back, and to be able to re-start configuration from the middle.  These
  goals may be incompatible with any language whose implementation we do
  not fully control unless it is allowed to execute only in isolated and
  independent snippets.  These are not hard goals, but it is a trade-off
  to keep in mind.  Stephen may be able to elaborate more on the snapshot
  approach if needed.

I think these goals aim towards a faster configure, and the ability to only
partly reconfigure, right ?

> * A problem with the current design is that the entire configuration
process
  is logically serial making parallel evaluation hard or impossible.  In
  many cases each add_subdirectory can be processed independently, but this
  will require semantic changes to allow.

I know I am largely biased by the project I work on, but I do not see how
parallel evaluation woud be a huge benefit. We basically have a "core"
library, and lots of libs that link against it (and other libs, such as
third parties).
How would a target B that depends on lib A be processed in this case ?
Wouldn't the evaluation of the link_libraries of B be waiting for the
evaluation of A to finish ?
If this is the case, then parallel evaluation would be only a slight
benefit (again, heavily biased by the project I work on).
And how would that work with CMakeLists that affect their parent scope ?

> Ideally most of the specification (sources, libraries, executables, etc.)
should be in a pure format that can be evaluated without side effects (e.g.
declarative or functional).

I'm not sure I understand how this could be done without losing a lot of
what CMake offers, such as copying or generating files.
I'm leaning towards a declarative approach as it is quite easy to learn
(since you declare objects, and every C++ programmer I know is familiar
with those), and functional, while powerfull and very elegant for some
things, is quite foreign to C+ programmers as a whole (I know C++11 adds
this, but it will be years until this can be used in production for lots of
C++ users, because of old compilers that are still supported for business
reasons).
Moreover, object-oriented is easy to introspect, offering an abstract
representation for IDEs and tools.

It seems you are leaning towards pure functional, but I do not see how this
would work with the current way CMake handles variables and scope, could
you elaborate ?


> I do not think we should have the build specification depend on processing
code like this.  It is not compatible with cmake-gui where the configuration
and generation steps are triggered by the user.

My POC is far from complete, and what I had in mind to keep the CMake-gui
approach was to make generating optional in CLI through a parameter. Thus
executing the script would only configure, which would populate the
CMakeCache, allowing the user to modify variables and such, then configure.
To clarify, only the following lines should be considered when looking at
the POC.
> myProject=cmake.Project("MyTestProject")
> myProject.targets=[cmake.SharedLibrary("testLibrary",["lib.cxx"])]


> In summary, I think work in this direction should first focus on designing
a declarative (or functional) specification format where most of the project
information can be specified.  Then a cmake-language command can be written
to load and evaluate a specification file (as a transition).  Finally we
could look at replacing the entry-point language with something else.  At
that point we could have closures passed as parameters to the evaluation of
the pure spec in order to get custom generate-time logic.

It seems you have in mind to write a new CMake language. I'd rather see an
existing language used, such as OCaml or lisp if you want a pure functional
language. Those are supported by SWIG so prototyping would be easy.
Javascript is even an option that is not *completely* crazy, as it has a
C-Style syntax  so it would be an easy language to write in for C++
programmers.

I think using an existing language has quite a few benefits:
* no need to design or implement a language
* lots of existing resources on how to do things
* lots of existing libraries (data structures, file system operations, etc)
* tooling (auto-complete, debugging, profiling, linting, etc)

Maybe I should take my POC further, in order to see the failings of this
approach, and maybe the same should be done for a more functional approach.
CMake's own buildsystem seems like a good testing ground for this, but it
is a little too big for a first go, do you know of a small CMake-based
project that would be better suited ?

I don't have a clear view of what a pure functional CMake would look like,
but if you give me some mock code, I could give a try at bringing some pure
functional language up to the level of my POC and we could use it as a more

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

[Aleix Pol]

On Sun, Jan 10, 2016 at 12:10 PM, Stephen Kelly  wrote:
>
> 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 information about the buildsystem, and about the content of the
> cmake files themselves:
>
>  
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/12658/focus=13004
>
> The original post in that thread lists design goals.
>
> This design is independent of any generator, and compared to the solution of
> writing json to a file, this solution doesn't require generating
> anything that is
> not asked for.  This also side-steps the problem of 'stale' files remaining
> in the build directory, and the problem of needing to trigger re-generation
> of the file, or watching it for changes.  This solution also allows
> parameters (eg the config) to be specified in requests, side-stepping a
> difficulty we encountered before to represent things like that.  This
> solution also does not require actually generating the buildsystem
> files. Only the configure and compute steps of cmake are executed.
>
> I am scheduled to give a talk at FOSDEM about the feature and how user
> tools can interact with it:
>
>  https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code
>
> with a preview in Berlin:
>
>  http://www.meetup.com/berlincplusplus/events/227896427/
>
> I have now also pushed a branch to my github clone with the start of the
> server mode:
>
>  https://github.com/steveire/CMake/commits/cmake-daemon
>
> Currently the branch only makes targets and backtraces etc available via
> the protocol.  I have also created a plan for extending the protocol to
> make code completion and variable debugging possible, and analysed the
> depedencies of the tasks:
>
>  http://www.steveire.com/cmake-daemon-tasks.png
>
> However, I can't complete those tasks myself: I don't have
> relevant experience building IDEs to know how best to design the
> protocol, what IDE tools really need, how to design a fail-safe parser
> etc.  Additionally, I think a design which incorporates design ideas
> and implementation from more than one person will be better in the end.
>
> So, this needs to be a collaborative effort if it is to go anywhere, with
> more people writing commits in the cmake repo.
>
> The above (copied below) task list would be enough to get a read-only
> browser of a cmake project quite quickly.
>
> Following that, an effort would be needed to handle the difference
> between the dirty state of an editor and the on-disk file content. That's
> a solvable problem and together with filesystem notifications provided
> by libuv, it will lead to features like code completion.
>
> Also necessary eventually would be to make the cmake parser more
> fail-safe, so that information is still available if the user
> had not yet closed a command argument list for example, and make the
> processing more fail-safe in the case where they have written
> add_subdirectory(foo), but have not yet created foo/CMakeLists.txt.
>
> I would be looking to people who work on IDEs for guidance on how to do
> things like that, as some of them are likely already for handling C++
> code in the IDEs.
>
> So, this needs to be a collaborative effort. I can provide guidance to
> anyone who wishes to participate in changing the source code of CMake
> to make it possible.
>
> Is anyone interested enough in this potential cmake feature to
> join the development effort?
>
> Thanks,
>
> Steve.
>
>
> * Provide basic daemon mode with event loop and communication protocol
> -- Written, but not reviewed
> * Provide protocol to query the buildsystem structure
> -- Written, but not complete or reviewed
> * Extend cmListFileParser to record location of start and end of commands
> * Rewrite cmIfCommand to record which branches are executed
> * Store the location of start and end of user-defined functions
> * Provide protocol to query for unexecuted lines
> * Define a new snapshot type to occur at an arbitrary point
> * Create snapshots after branching to other files (after an include() or
> find_package() or add_subdirectory etc)
> * Create snapshots after points with external effects (file(WRITE),
> configure_file(), execute_process etc)
> * Find most recent snapshot occuring before a specified line
> * Implement feature to start at a specific snapshot and execute commands
> up to a particular line
> * Make server find correct snapshot to start at and execute required
> commands up to specified line
> * Provide protocol to dump variable defintions at a particular line
> * Extract implementation of IssueMessage from cmMakefile and
> cmLocalGenerator into cmake
> * Extract computed target properties from cmTarget::GetProperty into
> cmComputedTargetProperties
> * Implement 

Re: [cmake-developers] VS_GLOBAL_ properties in VS 2010+ (was: patch building and testing)

[Brad King]

On 01/08/2016 05:56 PM, Mike Fitzgerald wrote:
> I've got the attached, which gives me the results I'd expect

Great, thanks.  I've applied this and merged to 'next' for testing:

 VS: Implement VS_GLOBAL_* target properties in VS 2010+ (#13666)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af39f115

> If I should be adding a test for this property

The property has an existing smoke test in Tests/VSResource but that
does not actually check that anything works.  The above-linked change
is acceptable on its own since the existing property was not tested
for VS 2008 and below even though it was implemented.  However, we'd
appreciate it if you could look at adding tests.

Take a look at

 Tests/RunCMake/XcodeProject
 Tests/RunCMake/SolutionGlobalSections

These directories have test cases that check the actual content of
the generated Xcode projects and VS .sln files.  Something similar
could be added to check for the results of this property in .vcxproj
files.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMake alternative language (was: Using CMake as a library from Python)

[Pau Garcia i Quiles]

On Fri, Jan 8, 2016 at 5:30 PM, Brad King  wrote:


> See above.  Lua has come up several times in the past in particular because
> its implementation is meant to be small and embeddable.  I've thought a few
> times about how to make Lua scripting available from within the CMake
> language
> in a clean way, but that will not be as valuable as the above pure-spec
> approach.
>
>
Please, do not do that.

The moment you make CMake scriptable in more than one language, you are
forcing every CMake user to learn that additional language because sooner
or later he will step into a third-party that is using that additional
language.

IMHO, if you want Lua, then Lua it is. But then please get rid of CMake
scripting.

BTW, I am sure you are aware of CMakeScript, CMake scripting in JavaScript:

http://sourceforge.net/projects/cmakescript/

Also, declarative? Why? There are already a few declarative build systems
(e. g. qbs, one of the reasons for its existence was CMake was not
declarative). By moving CMake from the current procedural scripting to a
declarative approach, you may alienate your current user base and be good
for none anymore.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Fwd: FindwxWidgets.cmake

[Simon Wells]

The following code is line 191-201, I have tested without this being set on
OSX 10.11 using system clang and both self-built and brew installed
wxwidgets with no problems, Whether its still an issue using gcc on osx or
some other configuration i am unsure, but is it worth being more specific
than just If APPLE for this bug-fix/workaround


# Using SYSTEM with INCLUDE_DIRECTORIES in conjunction with wxWidgets on
# the Mac produces compiler errors. Set wxWidgets_INCLUDE_DIRS_NO_SYSTEM
# to prevent UsewxWidgets.cmake from using SYSTEM.
#
# See cmake mailing list discussions for more info:
# https://cmake.org/pipermail/cmake/2008-April/021115.html
# https://cmake.org/pipermail/cmake/2008-April/021146.html
#
if(APPLE OR CMAKE_CXX_PLATFORM_ID MATCHES "OpenBSD")
set(wxWidgets_INCLUDE_DIRS_NO_SYSTEM 1)
endif()


thanks

Simon
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers