[cmake-developers] CMake, Ninja and Clang on windows?

[Tobias Hunger]

Hi CMake Developers,

we are currently trying to support Clang (without the -cl;-) on
Windows. This fails since CMake adds extra compiler flags to the
command line which are not in the expected format.

Stackoverflow[1] suggests to set CMAKE_SYSTEM_NAME to "Generic" to
stop that from happening.

The blog post[2] referenced by StackOverflow suggests setting
CMAKE_C_FLAGS and CMAKE_CXX_FLAGS to TRUE.

Both approaches seem like big hammers to me. Are there better ways to
get this going that will have less potential side effects?

Best Regards,
Tobias

[1]: 
https://stackoverflow.com/questions/46553436/building-with-cmake-ninja-and-clang-on-windows#46593308
[2]: 
https://metricpanda.com/rival-fortress-update-27-compiling-with-clang-on-windows
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Cmake-server question

[Tobias Hunger]

On Thu, Feb 15, 2018 at 3:18 PM, Ben Boeckel  wrote:
> On Wed, Feb 14, 2018 at 19:19:39 +0100, Paweł Rutka wrote:
>> I would like to ask about some important feature:
>> Is there any possibility to provide form Cmake Server side location of
>> command that generate the target? The Use Case is as follow:
>> In IDE you want  to, after Class creation, automatically add CPP file into
>> proper add_executable or extend some variable passed to  add_executable or
>> any other case that lead to target creation.
>
> Note that this is a very hard problem. Take the following examples:

I am very aware that adding files to cmake targets is a hard
problem:-/ That's why Creator does not even try to do it. It is bound
to do it wrong and thus users can not trust the functionality.

If there is any chance to solve this problem, then inside cmake. At
least you and your code do fully understand the cmake language.

Best Regards,
Tobias
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Server handshake with only build directory

[Tobias Hunger]

Hi Rich,

On Mon, Jan 22, 2018 at 5:48 PM, Rich Chiodo  wrote:
> If you have the build directory, can’t you just parse the CmakeCache.txt?
> CMAKE_HOME_DIRECTORY in the cache is the source folder. Seems easier than
> writing something to talk to CMake server.

Sure, but part of the reason to have server-mode is to get rid of
clutches like that.

If nobody objects, then I can make server-mode start with a build
directory only. I had that implemented at some point, but removed it
as part of the review process.

Any objections from the core team about enabling server-mode with a
build directory only? I can send in a patch, it is simple to add this.

Best Regards,
Tobias
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Server handshake with only build directory

[Tobias Hunger]

Hi Isaiah,

the idea was to make sure the IDE and cmake agree on the settings
being used and to make it very explicit what is going to be used.

Best Regards,
Tobias

On Mon, Jan 22, 2018 at 4:54 PM, Isaiah Norton  wrote:
> I'd like to use cmake server with only a build directory argument (mostly in
> order to query the cache), but receive an error in return:
>
> ```
>> cmake --version
> cmake version 3.9.4
>
>> cmake -E server --experimental --debug
>
>> [== "CMake Server" ==[
>> {"cookie":"zimtstern","type":"handshake","protocolVersion":{"major":1},
>> "buildDirectory":"/opt/bld/s5nj/Slicer-build"
>> }
>> ]== "CMake Server" ==]
>
> [== "CMake Server" ==[
> {"cookie":"zimtstern","errorMessage":"Failed to activate protocol version:
> \"CMAKE_HOME_DIRECTORY\" is set but incompatible with configured source
> directory value.","inReplyTo":"handshake","type":"error"}
> ]== "CMake Server" ==]
> ```
>
> The docs example with source and generator arguments works -- but shouldn't
> the build directory fully determine these options for an already-configured
> build tree?
>
> Thanks,
> Isaiah
>
>
> --
>
> 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:
> https://cmake.org/mailman/listinfo/cmake-developers
>
-- 

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMAKE Generator for Embacardero RAD Studio IDE

[Tobias Hunger]

On Nov 17, 2017 15:14, "Brad King"  wrote:

> Or perhaps, there is some technical issue related to this particular
> IDE that makes it impossible to support such IDE.

I'm not familiar with that IDE, but in order to be directly supported
by a generator its native build system would need to support everything
in CMake's code model (static/shared/exe binaries, custom commands, etc.).


This is only necessary if that IDE has a built-in build system like Visual
Studio has. If the IDE uses other build systems in the background, then
this seems like overkill to me.

An alternative is to create an "extra" generator that produces project
files that sit next to Ninja or Makefile generator outputs.  The latter
is the real build system.  The extra project files are for the IDE.


Extra generators are a horrible hack IMHO and we should strive to get rid
of them and not encourage users to add more.

I would suggest to write some python script using CMake server-mode to
extract data out of CMake and then generate files in whatever syntax this
IDE requires.

Best Regards,
Tobias
-- 

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-server protocol versioning

[Tobias Hunger]

Hi Justin,

On Thu, Sep 14, 2017 at 6:52 PM, Justin Goshi via cmake-developers
 wrote:
> I work at Microsoft on the version of CMake shipping with Visual Studio, and
> we use the cmake-server to talk to CMake.

Cool!

> At some point between cmake version 3.9.0 and 3.9.1 the cmake-server
> protocol changed. Looking through the source code, I see that
> cmServerProtocol1::ProtocolVersion now returns 1,1 when it used to return
> 1,0. Has there been discussion about backwards compatibility? In particular
> we were thinking something along these lines would be nice.

Please ask the server for version 1, not 1.0 (leave the minor part
unspecified). That way server-mode will always return the latest minor
version that is available.

> Every change to the information returned from CMake increments the protocol
> number

It does. As new functionality gets added, the version number
increases, as you noted.

> CMake –server supports all protocol numbers by letting you specify which one
> you are requesting. Extra data that is ignored is okay with older protocols,
> but it can’t change the expected data.

That is what minor increments do: They add extra stuff that older
clients should simply ignore. This means new fields might get added to
the JSON output, or new commands may become available. Nothing that
should throw a client off balance:-) Minor version bumps are mostly
there to make clients aware that new features are available.

Major version bumps break compatibility with clients that expect
earlier major versions. We will keep the old version of the protocol
supported when that happens -- as far as that is possible.

> CMake –server has tests to verify it supports older protocol numbers.

Tests are available for a lot of the things that server-mode does.
They did not detect a regression compared to protocol 1.0 when we
changed to 1.1.

I would welcome if you could find the time to help improve our test
coverage with use-cases critical to you.

> What are your thoughts?

I basically agree with what you said. But please be aware that
server-mode is still experimental, so we do currently have a bit of
slack as we figure out things.

We should discuss removing the experimental tag though.

Best Regards,
Tobias
-- 

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] Dependency graph in server mode?

[Tobias Hunger]

Hi Eric,

On Fri, Aug 25, 2017 at 3:53 PM, Eric Noulard  wrote:
> Is it possible to get the dependency graph one can get with the --graphviz
> option when running in server mode.

Not yet:-)

> From my understanding the current "codeModel" message does not contain such
> information. Am I right?

Yes, that kind of information is not in the codeModel.

> If I wanted to add the dependency information would it be better to create a
> new server mode
> message or put that into current "codeModel"?

Please put that into a separate message.

Best Regards,
Tobias
-- 

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] Targets with same name in different projects

[Tobias Hunger]

Hello,

I found a project recently which looks odd in the Qt Creator project
tree. Looking into it I found that this project has several projects
defined and two of those define the same target (same SOURCE file,
same name, etc.). It seems like both projects somehow include the same
CMakeLists.txt file defining that target (have not yet checked for the
specifics).

So I was wondering: Is this even allowed? The CMake manual says target
names must be unique within a project. I had always read that as
"unique within one build system", but now I am confused:-) Maybe this
is actually about PROJECTs defined in CMakeLists.txt files?

If different PROJECTs may have targets with the same name: How do I
call cmake to build one of those targets via the command line
interface but not the other?

Best Regards,
Tobias
-- 

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] [Qt-creator] ​Qt Creator vs CMake server mode

[Tobias Hunger]

Hi all,

On Fri, Feb 10, 2017 at 1:08 AM, Mike Jackson  wrote:
> I can confirm with QtCreator 4.3 nightly builds and CMake 3.7.1 those
> "utility" targets do not show up.

Server-mode reports the following targets: EXECUTABLE, STATIC_LIBRARY,
SHARED_LIBRARY, MODULE_LIBRARY, OBJECT_LIBRARY, UTILITY and
INTERFACE_LIBRARY, provided they are not marked as "IsImported".

So these should be reported and I do see lots of UTILITY targets in
the project tree of creator.

Best Regards,
Tobias
-- 

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] Debugger for CMake

[Tobias Hunger]

On Jan 30, 2017 20:03, "Sylvain Joubert"  wrote:

> c) What is the best

> approach to make this kind of feature appealing to IDE / UI tools which
> currently work with CMake?
>
>
If I recall correctly, one of the initial use cases for the server mode was
exactly that. The very first prototype of Stephen Kelly had this feature
and could trace were a variable was last modified, make a diff of the CMake
state between two locations in a CMake script,...


I liked the snapshots that were in Stephen Kelly's daemon-mode patch much
better than an interactive debugger.

Those much easier to use and visualize for an IDE than having an
interactive debugger. And they make much more sense IMHO: You can see state
and how that changes in every line instead of just the current one.

I didn't look at your code and I'll let the server mode maintainers give
their feedback too but I guess the best way to go would be to jump in
server mode to add that. Besides, the server mode is especially designed to
be IDE friendly.


I want to add support for snapshots as soon as they are available in cmake.

Is somebody working on the snapshot infrastructure? That is way too deep in
core cmake components for me to feel comfortable to implement. I will of
course happily write the code to integrate that into server mode:-)

Best Regards,
Tobias
-- 

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] CMake server-mode aborting

[Tobias Hunger]

Hello CMake developers,

I have been using Qt Creator extensively with cmake server-mode for a
while now and am very happy with the results so far. Once the project
is initially configured by cmake it is really nice.

Today I started to look into a bug report that creator behaves
horribly when not all the dependencies of a project are available. In
that case the UI behaves entirely wrong (I just pushed a patch to
improve that on the Creator side into code review).

The root cause seems to be that during configure run CMake just
vanishes. Creator reports back that it crashed. I can unfortunately
not reproduce that problem with any of the CMakeLists.txt files I have
handy, so I am a bit lost at what to do.

Does any of you cmake experts have an idea what might go wrong? I
thought that maybe a MESSAGE(FATAL_ERROR ...) is triggered, causing
cmake server to terminate or something similar. Unfortunately that
does not seem to trigger the server to die for me:-/

Best Regards,
Tobias
-- 

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] How to use cmake::SetCacheArgs(...)?

[Tobias Hunger]

Am 30.11.2016 19:10 schrieb "Brad King" :
> If you want to ensure a fresh one-step configuration then always remove
> CMakeCache.txt and CMakeFiles/ before configuring.

People are really attached to their configuration and get upset when
creator runs CMake. Creator running CMake with arguments is even more
hated. Cleaning all settings and starting over with a clean configuration
is the epitome of evil:-)

Considering that there is no good way to figure out which settings were
done by the user and what is auto-detected, it is basically impossible to
restore the configuration from within Qt Creator:-(

Users do set configuration options from within Qt Creator *and* from the
command line, so I would need help from CMake to figure out the complete
set of settings done by the user.

Best Regards,
Tobias
-- 

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] How to use cmake::SetCacheArgs(...)?

[Tobias Hunger]

Hello CMake developers,

I am trying to pass a number of arguments to cmake server-mode's
configure command. The exact call is:

[== "CMake Server" ==[
{
"cacheArguments": [
"-DCMAKE_BUILD_TYPE:STRING=Debug",
"-DCMAKE_CXX_COMPILER:STRING=/usr/lib/ccache/bin/g++",
"-DCMAKE_C_COMPILER:STRING=/usr/lib/ccache/bin/gcc",
"-DCMAKE_PREFIX_PATH:STRING=/usr",
"-DQT_QMAKE_EXECUTABLE:STRING=/usr/bin/qmake"
],
"cookie": 2,
"type": "configure"
}
]== "CMake Server" ==]

These are then fed into cmake::SetCacheArgs(...) by server-mode. That
call succeeds and I do see my values in the Cache once that is done
(via cmCacheManager::PrintCache(...)).

I then proceed to call cmake::Configure(...). That says something
about having to start over with a clean cache since the compiler
changed (which is correct).

After cmake::Configure(...) returns values some of the values are gone
again. E.g. CMAKE_BUILD_TYPE changed back from "Debug" to "".

Is this expected behavior?

When I resend the configure command to the cmake server all values stick.

Is that what I need to do? How do I know whether or not I need to
rerun configure again? Is there any telltale sign or at any
machine-readable notification that I need to send my data again? Or is
the procedure to just rerun configure with all arguments till the
cache no longer changes?

Best Regards,
Tobias
-- 

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] improved CodeBlocks group support

[Tobias Hunger]

Hi Tim,

Am 21.11.2016 01:19 schrieb "tim cotter" :
>
> i've patched my local cmake to automatically add a virtual folder group
option for every file in a code blocks project.
>
> it's not proper support for cmake source groups.
> but it does what i want it to do.
>
> the patch is small.
>
> would the community be interested in such a thing?

Have you tested this with the IDEs that user this extra generator?
CodeBlocks and QtCreator are the ones I know to be using this.

> if so, how would i go about submitting it?

If you can create a merge request at gitlab.kitware.com, then that would be
the best option. Not sure you can get an account there (that is able to
create merge requests).

Otherwise sending it here will probably work, too.

Best Regards,
Tobias
-- 

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] Current deficiencies of automoc

[Tobias Hunger]

Hi!

Am 20.10.2016 21:08 schrieb "Brad King" :
> On 10/20/2016 02:30 PM, Alan W. Irwin wrote:
> > To be specific here is the way I believe automoc should work.  If
> >
> > #include "moc_.cpp"
> >
> > is found in a source file under automoc
> > control, then if moc_.cpp could not be found in any of the
> > include directories for the target, then search those include
> > directories (including source-tree equivalents of build-tree include
> > directories) for .h, run moc on that file and place the result
> > moc_.cpp in the build directory corresponding to .
> [snip]
> > this is a plea to the CMake developers to fix the above deficiency

If you include moc_name.cpp, then you need to run moc on this *source*
file. That is what allows you to have private classes in your source file
that derive from QObject.

The headers should be covered by automoc automatically: Any header
containing a Q_OBJECT macro should be moc-ed. So there should not be any
need to include moc_*.cpp files in source files for any header.

At least that is how I always use this with qmake, but I am hardly an
expert on how moc should work:-)

Best Regards,
Tobias
-- 

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] Is there a way in CMake to get a list of all CTest tests added with add_test?

[Tobias Hunger]

On Mo, 2016-10-03 at 14:25 -0400, Brad King wrote:
> > The list we need would thus be built up to contain all COMMAND
> > arguments to add_test that are also build targets in CMake.
> 
> The list would also need to include targets mentioned in generator
> expressions such as `$`.  This will almost certainly
> be better done as a CMake feature implemented in C++.  This was actually
> an early design philosophy: do the hard stuff in C++ so that complex
> logic is not needed in CMake-language code.

Access to the list of defined tests would be nice to have in the server-mode,
too:-)

If some work is done in that direction, please keep server-mode in mind when
designing the APIs. I would love to reuse them to expose that information to
clients.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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 server mode

[Tobias Hunger]

Hi Michele,

cmake -E server mode will always trigger something in cmake, so the
help will report that. I think it is nicer to report "Server mode
unavailable" when somebody attempts to run "cmake -E server" when that
is not available than to produce a "Unknown command".

To check whether or not server mode is available you can run "cmake -E
capabilities": That has a "serverMode" key with a boolean in its JSON
output. Easy to parse:-)

Gcc 4.8 should be new enough to enable it, there is only very light
C++11 usage, but I admit that I am not sure about MSVC2010.

Your build errors seem unrelated to server-mode.

Best Regards,
Tobias

On Thu, Sep 29, 2016 at 1:18 AM, michele pagot  wrote:
> I'm interested in the cmake server mode. I've started from
> https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ and
> then to  https://github.com/steveire/CMake.git and finally to the cmake
> official  git master branch as it seems e
>
> I rebuilt it from scratch on Windows trying both VS2010 and MinGW. With this
> second one, using gcc4.8. Everything seems fine as the build works as
> expected and
>
> the inline help report server mode with both compilers.
>
>
>>> c:\..\cmake\cmake_master\build\buils_vs2010\bin\Debug\cmake.exe -E
>> CMake Error: cmake version 3.6.20160928-g9a9b9
>> Usage:
>> c:\...\cmake\cmake_master\build\buils_vs2010\bin\Debug\cmake.exe -E
>>  [arguments...]
>> Available commands:
>>   capabilities  - Report capabilities built into cmake in JSON
>> format
>>   chdir dir cmd [args...]   - run command in a given directory
>>   compare_files file1 file2 - check if file1 is same as file2
>>   copy ... destination  - copy files to destination (either file or
>> directory)
>>   copy_directory ... destination   - copy content of ...
>> directories to 'destination' directory
>>   copy_if_different ... destination  - copy files if it has changed
>>   echo [...]- displays arguments as text
>>   echo_append [...] - displays arguments as text but no new line
>>   env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]...
>> - run command in a modified environment
>>   environment   - display the current environment
>>   make_directory ...   - create parent and  directories
>>   md5sum ...  - create MD5 checksum of files
>>   remove [-f] ... - remove the file(s), use -f to force it
>>   remove_directory dir  - remove a directory and its contents
>>   rename oldname newname- rename a file or directory (on one volume)
>>   server- start cmake in server mode
>>   sleep ... - sleep for given number of seconds
>
>
> but as I try to use it:
>
>>> cmake -E server
>> CMake Error: CMake was not built with server mode enabled
>>
> First issue: server reported in the help even if not included
>
>
> the  new feature seems to be activated only if some special compiler
> capability are fulfilled. So I've changed compiler to gcc5.3 and now I'm
> even nor able to build due to errors like:
>
>
> [  2%] Building CXX object
> Source/kwsys/CMakeFiles/cmsys.dir/RegularExpression.cxx.obj
>
> [  2%] Building CXX object
> Source/kwsys/CMakeFiles/cmsys.dir/SystemTools.cxx.obj
>
> c:/userdata/draft/cmake/cmake_master/cmake/Source/kwsys/SystemTools.cxx: In
> member function 'bool cmsys::SystemToolsPathCaseCmp::operator()(const
> string&, const string&) const':
>
> c:/userdata/draft/cmake/cmake_master/cmake/Source/kwsys/SystemTools.cxx:465:43:
> error: 'strcasecmp' was not declared in this scope
>
>  return strcasecmp(l.c_str(), r.c_str()) < 0;
>
>^
>
> c:/userdata/draft/cmake/cmake_master/cmake/Source/kwsys/SystemTools.cxx: In
> static member function 'static bool cmsys::SystemTools::ComparePath(const
> string&, const string&)':
>
> c:/userdata/draft/cmake/cmake_master/cmake/Source/kwsys/SystemTools.cxx:4289:43:
> error: 'strcasecmp' was not declared in this scope
>
>return strcasecmp(c1.c_str(), c2.c_str()) == 0;
>
>^
>
> make[2]: *** [Source/kwsys/CMakeFiles/cmsys.dir/SystemTools.cxx.obj] Error 1
>
> make[1]: *** [Source/kwsys/CMakeFiles/cmsys.dir/all] Error 2
>
> make: *** [all] Error 2
>
>
>
> Fixed by:
>
> #endif
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
> #include 
>
>
>
>
>
>
>
>
>
>
>
> c:/userdata/draft/cmake/cmake_master/cmake/Utilities/cmlibarchive/libarchive/archive_read.c:825:1:
> error: conflicting types for 'archive_read_data'
>  archive_read_data(struct archive *_a, void *buff, size_t s)
>  ^
> In file included from
> c:/userdata/draft/cmake/cmake_master/cmake/Utilities/cmlibarchive/libarchive/archive_read.c:51:0:
> c:/userdata/draft/cmake/cmake_master/cmake/Utilities/cmlibarchive/libarchive/archive.h:581:24:
> note: previous declaration of 'archive_read_data' was here
>  __LA_DECL la_ssize_t   archive_read_data(struct archive *,
> ^
> 

Re: [cmake-developers] [PATCH] QtCreator integration: C++ includes must come first

[Tobias Hunger]

Hello CMake developers,

CMake used to break C++ projects in its CodeBlocks generator. Now it
probably breaks C projects.

I think the approach is wrong: C and C++ includes should never get
concatenated. Please consider to report compiler flags/include
paths/defines by language. You might want to keep the concatenated
information for backwards compatibility.

CMake 3.6 changed the include paths in the CodeBlocks generator to not
be in random order -- which might actually have caused the issue Kevin
is seeing. The IDEs using CodeBlocks generator seem to be pretty
robust at the Include paths front... considering there were no
complaints for *years* about the broken include paths ordering. So
maybe it is safe to not bother about backward compatibility here.

Best Regards,
Tobias

On Fri, Aug 26, 2016 at 3:59 PM, Brad King  wrote:
> On 08/25/2016 02:54 PM, Kevin Ottens wrote:
>> When using the Clang Code Model in QtCreator, it turned out that having
>> the C system include dirs can make it report false positives for most
>> uses on the STL. This is due to the order the Clang Code Model looks at
>> the include directories and some C includes in /usr/include could be
>> incompatible with the used STL if found first.
>
> Thanks, applied:
>
>  CodeBlocks: List C++ includes first
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=38995d19
>
> -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] Unix makefile: concurrent build configurations

[Tobias Hunger]

Hi Steve!

On Do, 2016-08-18 at 15:37 -0500, Steve Lorimer wrote:
> New to this list, so apologies if it's been discussed before.
> 
> I'd like to know why it's not possible to have both debug and release mode
> builds configured at the same time for Unix makefiles?

You can have an arbitrary number of configurations at once, all nicely separated
from each other in their own build directory. Nobody stops you from having
several build directories after all.

> I am aware that some generators (eg VisualStudio) do allow this behaviour.
> Why can I not have the same behaviour with Unix makefiles?

IMHO VisualStudio is rather broken in that regard. Please do not let the
insanity pass over to Makefiles! :-)

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] Security in CMake

[Tobias Hunger]

Hi Egor,

Am 21.08.2016 12:34 schrieb "Egor Pugin" :
>
> > What are the attack scenarios you want to defend against? What should
not be possible in your system that currently is in CMake?
>
> At least downloading or executing bad scripts and commands.

What is the attack you want to stop? What are bad scripts and commands in
this context?

CMake runs lots of commands all the time. Most can be changed by a user,
many are changed by the generator based on environment and whatnot. Any of
these may be bad commands -- based on configuration.

Downloading can be done using internal commands or by running e.g. wget or
curl, both of which are pretty widely available on developer machines.

> > That forces me to keep more state in my head when reading
CMakeLists.txt files.
>
> CMake files are generated in my system. That's what I mean when I said
> 'based on CMake'.

Sure. But if CMake gets a secure mode for your generator and if that is
merged upstream, then I need to know about that when reading or writing
CMakeLists.txt.

> It's like compiler compiler like yacc, bison, lex, flex. They are
> producing output not for human readers, but for computer parsers.
> And that's why generated code is safe and insertions from users are not.

Generated code is safe only as long as you very tightly control the
environment CMake runs in.

> Also in the most cases there's no any insertions at all, so it's rare
case.

I'm sure you know what you are doing:)

Best regards,
Tobias
-- 

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] Security in CMake

[Tobias Hunger]

Hi Egor,

Am 20.08.2016 13:48 schrieb "Egor Pugin" :
>
> Hi,
>
> I'm working on a package manager based on cmake.
> And some cmake instructions are downloaded with user packages.
> I'd like to have an ability to deny some cmake features in such
> external untrusted insertions.

I am no CMake expert, but you are talking about securing a program that is
meant to take arbitrary input and run user-defined commands on that to
produce possibly executable output.

I do not see any safe subset of CMake commands that is still able to do
anything useful.

I can see a way for "insertions" to be useful, that does not involve them
changing the configuration (e.g. for a cross compiler), involve running
some 3rd party program (e.g. to add support for a new documentation system,
parser generator or whatnot), or the production of build artifacts (e.g.
build some library for the developer to use).

*All* of  these are inheritently unsafe.

Configuration change: Change the C compiler to rm and pass force -rf -- /
as flags.

3rd party program: Run rm -rf / when some certain input file is seen.

Build artifacts: Put running rm -rf / into the binary/library so that this
is run during normal development workflow.

I would try to run my package manager in an environment where running rm
-rf is harmless to the overall system health. Virtual machines or
containers spring to mind there. Not sure that is feasible.

Or come up with insertions signing, etc. so that users can at least know
they got what was uploaded and know whom to blame when their systems get
wiped.

Beat Regards,
Tobias
-- 

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] cmake -E capabilities [v3]

[Tobias Hunger]

Hi CMake developers,

I am back to a internet-connected world, so here is a new update of
the cmake -E capabilities patch.

I did the changes Brad requested:
* Rebased on cmake master branch
* Add documentation
* Add a smoke test that makes sure that "cmake -E capabilities" can run.

Code is on github again:

https://github.com/hunger/CMake/commits/cmake-capabilities

Best Regards,
Tobias
-- 

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 -E capabilities [attempt 2]

[Tobias Hunger]

Hi Stephen,

thanks for taking the time to do such a thorough review!

I pushed an update that takes most of the feedback into account. Still at:

https://github.com/hunger/CMake/commits/cmake-capabilities

On Wed, Jul 27, 2016 at 1:11 AM, Stephen Kelly <steve...@gmail.com> wrote:
> 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 commit has a cmDefinitions include though that should be removed.

Gone.

> * There are also some methods that should be const

Added const to some of them:-) Hope I caught all.

> * and a whitespace change that should be squashed into the commit that
> introduces it

I used Utilities/Scripts/clang-format.bash to do the formatting, so
that should not be an issue. I just reran that on all commits. Maybe I
forgot it in a commit or something before.

> * The pretty-print flag should be removed. Aside from being a boolean trap,
> it creates a interface segregation principle violation. See eg

Removed, even though I find it really useful when testing cmake on
mac/windows. I do have all the small helper tools on Linux, but
usually not on windows/Mac.

> * The CMAKE_BUILD_WITH_CMAKE macro should be in cmcmd.cxx wrapping the
> capabilities handling:
>
> #if defined(CMAKE_BUILD_WITH_CMAKE)
> else if (args[1] == "capabilities") {
>   cmake cm;
>   std::cout << cm.ReportCapabilities();
>   return 0;
> }
> #endif

Why?

> That define should not be used in ReportCapabilities.

That define seems necessary to keep the bootstrap test running.

> * Splitting the 'CMake: Refactor ExtraGenerator registration' commit into
> multiple commits would make it more reviewable, and more bisectable in the
> future.

Sorry, this is what you will get from me: I have to start at some
place and meddle through till things work again. I have to back-track
often.

Basically I need to get some functionality implemented completely and
then test that. Only afterwards can I spend time on making the patches
pretty.

If that is not acceptable, then please feel free to do necessary
changes yourself.

> As it is, it is doing many different things, none of which are mentioned in
> the commit message, and some of which it probably shouldn't be doing.
>
> For example renaming GetExtraGeneratorName to
> GetExternalMakefileProjectGeneratorName is probably not needed. If you
> really want to do it, then it should be in its own commit with its own
> commit message which justifies the change. As it is, it adds noise to the
> big commit and makes it harder to review. Minimal is always better with
> commits which do refactoring like that.

I undid that change. That is one of the things that I originally
removed and then realized last minute that it is needed somehow. So I
added it, not realizing that I had removed similar functionality
earlier.

> A general good rule of thumb (which helps reviews, and makes things
> bisectable in the future) is to do one thing per commit.

I agree that this is the ideal we all should all strive for, but you
are not going to get that from me anytime soon. At least not in the
cmake codebase.

Best Regards,
Tobias
-- 

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 -E capabilities [attempt 2]

[Tobias Hunger]

Did anyone find some time for a review yet?

Best regards,
Tobias

Am 22.07.2016 01:37 schrieb "Tobias Hunger" <tobias.hun...@qt.io>:

> Hello fellow developers,
>
> https://github.com/hunger/CMake/commits/cmake-capabilities
>
> has my attempt to get "cmake -E capabilities" merged -- in preparation of
> the
> server mode.
>
> Brad already merged a big chunk of the changes, but he wanted to see the
> extra
> generator registration cleaned up before continuing. That has happened in
> the
> new push: The first patch adds a cmExternalMakefileProjectGeneratorFactory,
> which has all the necessary information so that cmake no longer needs to
> create
> instances of all extra generators during startup.
>
> Extra generators can now alias others -- which is used for the KDevelop3
> generator. Maybe we can just remove that? The comments claim the generator
> is
> for compatibility with cmake 2.2. That would shave a couple of lines of
> that
> patch...
>
> The capabilities work on top of that branch is mostly unchanged, but
> exposes an
> "isAlias" flag. I now suppress all aliases in the output of -E
> capabilities  as
> I think it makes no sense to have new code announce compatibility bridges
> (and
> the last version already hardcoded KDevelop3 to be suppressed).
>
> Best Regards,
> Tobias
>
> --
> Tobias Hunger, Senior Software Engineer | The Qt Company
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
> 144331 B
> --
>
> 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
-- 

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] cmake -E capabilities [attempt 2]

[Tobias Hunger]

Hello fellow developers,

https://github.com/hunger/CMake/commits/cmake-capabilities

has my attempt to get "cmake -E capabilities" merged -- in preparation of the
server mode.

Brad already merged a big chunk of the changes, but he wanted to see the extra
generator registration cleaned up before continuing. That has happened in the
new push: The first patch adds a cmExternalMakefileProjectGeneratorFactory,
which has all the necessary information so that cmake no longer needs to create
instances of all extra generators during startup.

Extra generators can now alias others -- which is used for the KDevelop3
generator. Maybe we can just remove that? The comments claim the generator is
for compatibility with cmake 2.2. That would shave a couple of lines of that
patch...

The capabilities work on top of that branch is mostly unchanged, but exposes an
"isAlias" flag. I now suppress all aliases in the output of -E capabilities  as
I think it makes no sense to have new code announce compatibility bridges (and
the last version already hardcoded KDevelop3 to be suppressed).

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] Question over language bindings / daemon

[Tobias Hunger]

Hi Rick,

On Mo, 2016-07-18 at 00:59 +0100, RW via cmake-developers wrote:
> Question 1
> Will the new daemon mode if it's included have all the commands associated
> with a CMakeFile?
> (In other-words could I write a python library that could just pipe
> commands into it, instead of generating a separate CMakeFile)

It's server mode now:-)

No, daemon mode will provide commands to query the build graph etc., but it will
not be usable to feed CMakeLists.txt-commands to cmake one by one.

> Question 2
> I had a look at the way the functions are written within the code
> while I could extract a list of them using something like CppSharp (for
> example to extract a list of everything that inherits from cmCommand)
> There doesn't seem to be any metadata that describes arguments that are
> passed into a given function. (only that each function takes a vector of
> strings).
> Do you know if there's any xml or associated metadata (perhaps used to
> generate the docs) for which arguments are associated with a given function?

This in turn is in scope for server mode (not at the start, but later): That
information is a by-product of the idea of server mode helping IDEs with code-
completion of CMakeLists.txt files.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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 -E capabilities

[Tobias Hunger]

Ping?

On Mo, 2016-07-11 at 14:13 +, Tobias Hunger wrote:
> https://github.com/hunger/CMake/commits/cmake-capabilities
> 
> is in a state now that could use another review.



-- Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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 -E capabilities

[Tobias Hunger]

Hello Developers,

https://github.com/hunger/CMake/commits/cmake-capabilities

is in a state now that could use another review.

It addresses all the issues that Stephen brought up, with small patches
extending the information reported via GeneratorInfo bit by bit. Only
when all that is in place, the new cmake -E capabilities is added.

This now creates extra generators (all of them), which does not seem to effect
run time of cmake -E capabilities by much on Linux. I have not tested this on
Windows/Mac though as I do not have those platforms handy.

If that is not acceptable, then some string-parsing is going to be necessary.
I'd move that into cmake::GetRegisteredGenerators, where it is more of an
implementation detail than in the code that actually handles the capability
reporting.

Best Regards,
Tobias

-- Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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 -E capabilities

[Tobias Hunger]

Hi fellow Developers,

I just uploaded a new version of the cmake-capabilities. I would appreciate 
some input:-)

This version still does parsing of the generator names. Stephen rightfully said 
that is not nice, which I fully agree with.

But to avoid doing that I will need to create instances of generators and 
interact with those. Is that both safe and fast to do?

I am a bit afraid that one generator or the other might end up doing some 
expensive checks on startup or maybe write files somewhere or do similar things 
I do not expect.

Implemented changes include:

Version reporting:
* Rename "appendix" to "suffix"
* Report "dirty" in the version section separately (information available via 
macro in cmVersionConfig.h)

Code:
* Do not use auto and range based for loops
* Do not use std::unordered_map directly
* Sprinkle this-> over the code

Generators:
* Hide KDevelop3 generator

Best Regads,
Tobias


From: cmake-developers <cmake-developers-boun...@cmake.org> on behalf of Tobias 
Hunger <tobias.hun...@gmail.com>
Sent: Thursday, July 7, 2016 3:51:52 PM
To: Stephen Kelly
Cc: CMake Developers
Subject: Re: [cmake-developers] cmake -E capabilities

Hello,

On Tue, Jul 5, 2016 at 1:48 AM, Stephen Kelly <steve...@gmail.com>,
me, Stephen Kelly wrote:
>>> Such a feature would also work with cmake projects if the user chooses to
>>> use the XCode generator on mac or VS generator on Windows (or if someday
>>> we have a multi-config Ninja generator or so).
>>
>> How is a multi-config ninja generator better than just having to build
>> directories next to each other, each with one configuration? You might
>> save a bit of disk space (probably not a lot). Will you save a significant
>> amount of processing time?
>>
>> The one benefit I can think of is switching between configurations will
>> probably be a lot faster. But that is nothing that is done so often that
>> it warrants optimizing for IMHO.
>
> What I have in mind is not optimization. As you say, if this is not needed
> at this point for IDE integration, then we can drop the idea.

I still do not get why this feature exists at all. What is the benefit
of having it? Is it just because xcode supports it, so cmake should
to?

>> Either the clients do not care or they need to know which configurations
>> those are going to be.
>
> This can be retrieved by reading the STRINGS property of the
> CMAKE_BUILD_TYPE cache variable.

Oh, that sounds interesting. I'll need to investigate this:-)

Best Regards,
Tobias
--

Powered by www.kitware.com<http://www.kitware.com>
Kitware Inc. - leading edge, high-quality software<http://www.kitware.com/>
www.kitware.com
Kitware's mission is to create state-of-the-art software products and services 
in visualization and data processing using advanced quality software methods 
and ...




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
-- 

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 -E capabilities

[Tobias Hunger]

Hello,

On Tue, Jul 5, 2016 at 1:48 AM, Stephen Kelly ,
me, Stephen Kelly wrote:
>>> Such a feature would also work with cmake projects if the user chooses to
>>> use the XCode generator on mac or VS generator on Windows (or if someday
>>> we have a multi-config Ninja generator or so).
>>
>> How is a multi-config ninja generator better than just having to build
>> directories next to each other, each with one configuration? You might
>> save a bit of disk space (probably not a lot). Will you save a significant
>> amount of processing time?
>>
>> The one benefit I can think of is switching between configurations will
>> probably be a lot faster. But that is nothing that is done so often that
>> it warrants optimizing for IMHO.
>
> What I have in mind is not optimization. As you say, if this is not needed
> at this point for IDE integration, then we can drop the idea.

I still do not get why this feature exists at all. What is the benefit
of having it? Is it just because xcode supports it, so cmake should
to?

>> Either the clients do not care or they need to know which configurations
>> those are going to be.
>
> This can be retrieved by reading the STRINGS property of the
> CMAKE_BUILD_TYPE cache variable.

Oh, that sounds interesting. I'll need to investigate this:-)

Best Regards,
Tobias
-- 

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 -E capabilities

[Tobias Hunger]

Sorry for the late reply... we had a beta release and a new patch
level release out this week and I had to fix some bugs in both:-)

On Sun, Jul 3, 2016 at 1:30 PM, Stephen Kelly  wrote:
>> "KDevelop3",
>
>  This generator should probably be removed/hidden by now. It has
> confused users of more-recent KDevelop versions.

Yes, that should be hidden. I'll add that in the next update.

>> What do you think? What else should we report here?
>
> It looks like a good start. The intention of the output is to satisfy needs
> that consumers like you have, and I guess it does have what you need.

Obviously, or I would not propose it:-)

The hope is to get feedback from other potential users. But so far no
luck on that front:-/

>> Compared to the bug report mentioned above the fields "multiconfig" and
>> "recursive" are missing. I could not figure out how to get that
>> information:-/
>
> When I made the example in the issue tracker, 'recursive' meant 'you can cd
> to a directory and run the CMAKE_MAKE_PROGRAM there'. At the time, it was
> possible to do that when using the Makefiles generator, but not the Ninja
> generator.
>
> I think that capability has since been added for the Ninja generator, but I
> don't know if it is possible with the Xcode and VS generators.
>
> Would that be a useful thing to expose here in your view?

I think that information would be useful at some point. But it is not
needed before a project is opened.

>> I would also welcome some code review on the patch.
>
> 1) For consistency you should change
>
>  GetRegisteredGenerators
>
> to
>
>  this->GetRegisteredGenerators
>
> whether that is a preferred style is orthogonal to the fact that it's
> consistently used in cmake code.

Oh, sorry. I still find that horrible to read, so I only sprinkle
this-> over the code shortly before sending it in to review.

> 2) CMake has to build with toolchains which do not provide
> std::unordered_map. See uses of CMake_HAVE_CXX_UNORDERED_MAP for existing
> code which uses either std::unordered_map or std::unordered_map. (Yes there
> is room for improvement there, but such improvement is orthogonal to your
> branch).

Oh, too bad.

> 3) Similarly, CMake has to build with compilers which do not support
> cxx_range_for or cxx_auto_type. For the cmServer implementation that may or
> may not be the case, but within the cmake class, that's the way it is.

I'll fix that.

> 4) It seems that the
>
>  this->Generators
>
> member of the cmake class has the names of all generators (without 'extra'
> generators). It seems unfortunate to not use that container and instead
> parse the names out of the names from the GetRegisteredGenerators call by
> splitting on the ' - '. It leads to hard coded magic expressions like
> 'separator + 3', so it should be avoided if possible.

Yes, that is ugly.

> Is there another way of determining the extra generators supported by a
> given generator and avoiding parsing a string which we just generated? Can
>
>   const std::vector& supportedGlobalGenerators =
> extraGenerator->GetSupportedGlobalGenerators();
>
> be used somehow? Can you first loop over this->Generators to get the
> 'normal' generators, then loop over the extra generators, call that method
> to match things up and output the result?

Doesn't this require me to instanciate the generators? Won't that  be
potentially expensive?

> Or would it make sense to refactor the container members in the cmake class
> themselves to make this information more easily available for this use-case?
>
> 5) You use the term 'appendix' for the version, but 'suffix' is the more-
> commonly used name for that concept.

I'll change that.

Best Regards,
Tobias
-- 

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 -E capabilities

[Tobias Hunger]

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 in
> > the first place.
> 
> I think when using qmake with QtCreator, the user can choose the 
> configuration at build time by selecting it from the left-side menu.

I do not understand what you are getting at.

That widget already works for cmake projects in Qt Creator: It switches between
different build directories with different configurations.

> Such a feature would also work with cmake projects if the user chooses to 
> use the XCode generator on mac or VS generator on Windows (or if someday we 
> have a multi-config Ninja generator or so).

How is a multi-config ninja generator better than just having to build
directories next to each other, each with one configuration? You might save a
bit of disk space (probably not a lot). Will you save a significant amount of
processing time?

The one benefit I can think of is switching between configurations will probably
be a lot faster. But that is nothing that is done so often that it warrants
optimizing for IMHO.

> However, I don't think that is an immediate goal, and that information can 
> be added later easily if a client does need it.

I still think the information "this generator can handle multiple configurations
in one build directory" is useless to all clients I can think of.

Either the clients do not care or they need to know which configurations those
are going to be.

Best Regards,
Tobias

-- Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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 -E capabilities

[Tobias Hunger]

On Do, 2016-06-30 at 15:00 -0400, Brad King wrote:
> On 06/30/2016 09:51 AM, Tobias Hunger wrote:
> > Compared to the bug report mentioned above the fields "multiconfig" and
> > "recursive" are missing. I could not figure out how to get that
> > information:-/
> 
> There is no "recursive" generator, so that does not belong in the example
> anyway.  The Makefile generator does not produce recursive makefiles:
> 
>  https://cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.
> 3F

Great, one thing less to worry about:-)

> For "multiconfig", there is the cmGlobalGenerator::IsMultiConfig method.
> Something similar will have to be added to the generator factory APIs
> so that we can ask for this information without creating a generator.

Sorry for not knowing any better... But does it make sense to provide that
information?

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 produces at
that point?

Once I get the project structure I have the information on the generated
configurations -- incl. their names.

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 could also not yet figure out a way to retrieve information on supported
> > platforms and toolsets. At least I did get whether a generator supports
> > toolsets, but nothing similar seems to exist for the platform part.
> 
> We don't have any information on supported platforms or toolsets.
> The CMAKE_GENERATOR_PLATFORM and CMAKE_GENERATOR_TOOLSET settings
> take user-specified values and we pass them through to native tools.
> It is up to the user to provide valid values.

Looking at the code I am a bit confused:

All the generators that take a platform seem to get that set via the generator
name. E.g. there are
* "Visual Studio 10 2010",
* "Visual Studio 10 2010 Win64" and
* "Visual Studio 10 2010 IA64"
generators registered.

All these different names trigger a new generator to be created with different
DefaultPlatformName set up (even though the documentation string for the
generators reports the Win64/IA64 part as "[arch]", not platform).

Note that "Win64" gets mapped to a platform name of "x64" and "IA64" gets mapped
to "Itanium".

So far so good...


The cmake command line lets me apparently use "-A platform" to set
cmake::GeneratorPlatform. That will end up in the cache as
"CMAKE_GENERATOR_PLATFORM" (after some validation).

Generators will get that value from the cmMakefiles (where they move into via
the CMakeCache AFAICT). That information will be passed to the generator via the
SetGeneratorPlatform method, which will then override the default platform set
via the generator name.


Why can I specify the platform names in two different ways? Why do the two ways
disagree on the platform name ("Win64" vs. "x64")? Did you rename the concept
from architecture to platform at some point (or why does the documentation use
[arch] and the command line client "-A")? I guess there are interesting
compatibility considerations behind all this:-)

What is the preferred way to set up a Visual studio project nowadays? Should I
filter out the architecture specific generators in favor or using -A on the
command line or the other way around? Or do both cover completely separate use
cases?

If "-A" is the way to go, then I would like to try my hand at adding a method to
retrieve all valid platforms for a generator. CMake has a lot of code to find
those names (or hardcodes known names), so why not pass it on to the user?

So far I only looked into the visual studio generators, so I might have missed
something that blocks such a method in other generators.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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 -E capabilities

[Tobias Hunger]

On Do, 2016-06-30 at 14:16 -0400, Robert Maynard wrote:
> It might be worthwhile to have the version section to have an explicit
> dirty key instead of having to parse the string key to find that
> information out.

I'll make that information available in a separate patch and add it.

> Also wouldn't you want server-mode to be an empty dictionary, as in
> the future that would contain information like the wire format
> version, etc.

Getting the information here would be expensive (I would need to instanciate a
cmServer to get the information) and I do not really see too big a need to add
that information in the first place. Long-term I will just require a cmake with
server-mode and "serverMode": "false" is enough to tell the user that she needs
to update her cmake:-)

The decision of which protocol to choose to talk to the server will be made
later, in a different part of the code.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] cmake -E capabilities

[Tobias Hunger]

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
generators are available to cmake and more static information built into CMake.

There is actually a bug report about the need for this feature here:
https://gitlab.kitware.com/cmake/cmake/issues/15462

This is my attempt to solve the issue:
https://github.com/hunger/CMake/commits/cmake-capabilities

The output looks like this:
> cmake -E capabilities --pretty-print
{
   "generators" : [
  {
 "extraGenerators" : [],
 "name" : "Watcom WMake",
 "toolSetSupport" : false
  },
  {
 "extraGenerators" : [ "CodeBlocks", "CodeLite", "Eclipse CDT4", "Kate",
"Sublime Text 2" ],
 "name" : "Ninja",
 "toolSetSupport" : false
  },
  {
 "extraGenerators" : [
"CodeBlocks",
"CodeLite",
"Eclipse CDT4",
"KDevelop3",
"Kate",
"Sublime Text 2"
 ],
 "name" : "Unix Makefiles",
 "toolSetSupport" : false
  }
   ],
   "server-mode" : false,
   "version" : {
  "major" : 3,
  "minor" : 6,
  "patch" : 20160630,
  "string" : "3.6.20160630-g2c759-dirty"
   }
}

This is running on my Linux machine.

What do you think? What else should we report here?

Compared to the bug report mentioned above the fields "multiconfig" and
"recursive" are missing. I could not figure out how to get that information:-/

I could also not yet figure out a way to retrieve information on supported
platforms and toolsets. At least I did get whether a generator supports
toolsets, but nothing similar seems to exist for the platform part.

Does anyone have an idea how I could retrieve this information?

I would also welcome some code review on the patch. The remaining items on my
server-mode todo list are all about removing similar information from the
server-mode commands:-)

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] Please apply patch from https://github.com/hunger/CMake/commits/for-upstream to master

[Tobias Hunger]

On Mi, 2016-06-29 at 09:54 +0200, Rolf Eike Beer wrote:
> Am 2016-06-29 09:35, schrieb Tobias Hunger:
> > Hello Brad,
> > 
> > I currently get more than 2000 warnings when building cmake master, all 
> > about
> > missing overrides.
> > 
> > Could you please take the fix warning patch from
> > https://github.com/hunger/CMake/commits/for-upstream and apply it to 
> > master?
> > That fixes all those pesky override warnings.
> 
> This should be CM_OVERRIDE.

Changed.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] Please apply patch from https://github.com/hunger/CMake/commits/for-upstream to master

[Tobias Hunger]

Hello Brad,

I currently get more than 2000 warnings when building cmake master, all about
missing overrides.

Could you please take the fix warning patch from
https://github.com/hunger/CMake/commits/for-upstream and apply it to master?
That fixes all those pesky override warnings.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] daemon-mode meeting last Tuesday

[Tobias Hunger]

Hi Brad,
Am 27.06.2016 7:18 nachm. schrieb "Brad King" :
> I will take care of making libuv available within CMake's implementation
> prior to merging the server mode work.  See the "libuv in cmake" branch
> of this thread.

Perfect.

Sorry, I only noticed the other thread after sending my mail.

Best regards,
Tobias
-- 

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] daemon-mode meeting last Tuesday

[Tobias Hunger]

He everybody,

sorry, I am currently not making the progress I want. Qt Creator has
feature freeze coming up and I need to push some patches and fix some
bugs.

Brad, Daniel: You both mentioned wanting to use libuv. Is somebody
already looking into merging this into cmake? So far I just link
against the library and am done with it...

Stephen said 3rd party libraries would need to be checked into cmake
and that scripts exist to keep these libraries up-to-date. What can I
do to help getting this library available to all cmake users (so that
I can further shrink my patch set;-)?

On Mon, Jun 27, 2016 at 5:03 PM, Brad King <brad.k...@kitware.com> wrote:
> On 06/23/2016 05:19 PM, Tobias Hunger wrote:
>> I'll create a task to rename it to "server" then.
>
> Sounds good.
>
>>> Would each type of query have a known type of response?
>>
>> It has a type: "reply" (or "error"). I so far use the inReplyTo field to
>> specify what the request a reply refers to. Stephen thinks that is not
>> necessary as there is always one request in flight and the client can just
>> figure things out without additional information.
>
> Okay.  If the field makes debugging or other use cases easier I see no reason
> not to include it.

Good, I'll keep inReplyTo for now.

>>> Also, doesn't the cookie allow the query/response pairs to be matched?
>>
>> In theory yes. But a protocol should work without having to reply on cookies.
>
> Yes, I see.
>
>> The header currently is the type, inReplyTo and the cookie. I did not see
>> the need to separate those.
>
> Okay.  This may be easier to review in context when the time comes.

Ok, I'll keep things the way they are for now then. Changing that
should not be too hard anyway.

>>> Currently cmake-gui supports switching generators, build trees, etc., so
>>> there is some precedent for such switching within a single process.  If
>>> we have (re-)initialization bugs they should simply be fixed.
>>
>> So you think we should keep that?
>
> No.  See response in another branch of this thread.

OK, going for the command line switching model then.

>>> I'm not sure we have that information.  IIRC CMake only adds settings to the
>>> generated build system to tell the tools where to put the .pdb and what to
>>> call it if it happens to be created.
>>
>> I think CMake should know what is generated and should not leave decisions
>> like that up to generators.
>
> Yes, but that will take some additional investigation and work to achieve.
> CMake will have to be taught more about which tools/platforms actually
> produce the .pdb files.  They are not first-class artifacts in CMake's
> model right now.

I currently list the PDB files in the artifacts (if there is a .lib
file). I'll keep that for the time being.

Best Regards,
Tobias
-- 

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] daemon-mode meeting last Tuesday

[Tobias Hunger]

Hi Daniel,

On Fri, Jun 24, 2016 at 5:08 PM, Daniel Pfeifer  wrote:
>>> Currently cmake-gui supports switching generators, build trees, etc., so
>>> there is some precedent for such switching within a single process.  If
>>> we have (re-)initialization bugs they should simply be fixed.
>>
>> So you opt for enabling the cmake-server to switch between different
>> build directories?
>
> Clients who need this feature could simply restart the server in the
> new directory.

yes, that was what Stephen and me thought, too. I understood Brad to
imply that we should just do everything inside server-mode and fix any
fallout we run into instead.

That is why I wanted to have this clarified, as this does cause quite
a few changes in the implementation.

Best Regards,
Tobias
-- 

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] daemon-mode meeting last Tuesday

[Tobias Hunger]

Hi Brad,

On Thu, Jun 23, 2016 at 10:46 PM, Brad King  wrote:
>>   * This is currently used to set sourcedirectory, builddirectory and
>> generator.
>>
>> These three should be passed in via the command line instead, again
>> to avoid trouble with users switching to different build directories/etc.
>> while the daemon is running, which might trigger problems with state
>> cleanup, etc.
>
> Currently cmake-gui supports switching generators, build trees, etc., so
> there is some precedent for such switching within a single process.  If
> we have (re-)initialization bugs they should simply be fixed.

So you opt for enabling the cmake-server to switch between different
build directories?

That would have the following side-effects:

* We would need the reset command to get the server back into a defined state

* We need to keep it possible to set source directory, build directory
and generator from inside server mode

* We can keep the existing generators query-able from inside server
mode. If they are set inside server mode, then there is no need to
know them before starting server mode after all.

* The commandline way of querying generators is not necessary. We
might still want that, but it does not belong into this patch set
anymore.

Is this the way to do? I will need to back out some changes I did
since speaking with Stephen then. No problem, git has everything;-)

Best Regards,
Tobias
-- 

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] daemon-mode meeting last Tuesday

[Tobias Hunger]

Hallo Daniel,

On Fri, Jun 24, 2016 at 9:59 AM, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:
> On Thu, Jun 23, 2016 at 2:27 PM, Tobias Hunger <tobias.hun...@qt.io> wrote:
>>   * We both think it only makes sense to merge the infrastructure part into
>> cmake (if it passes review first of course) once we have some 
>> functionality
>> that is genuinely useful. So we want to aim at having the infrastructure
>> and the codemodel merged in one go.
>
> Please think about adding libuv earlier. As Brad wrote before, libuv
> could replace some #ifdef code that we currently have (process
> handling, file operations). I am currently refactoring the code around
> the cmOutputConverter and I would like to introduce a cmPath class (I
> will write more about that later, but I can already say that libuv
> might come handy for some functionality).

Feel free to merge it at your own pace. I'll just use your copy then:-)

Currently I just link to an external version of said library and have
not yet tried to figure out what the policy is wrt. 3rd party code in
cmake. Stephen suggested that we would need to include a copy into the
cmake repository and hinted at a script that keeps these copies
updated.

>>   2.7 cache (report contents of CMakeCache.txt file)
>>
>>   * Review by other potential users would be appreciated, but no obvious
>> problems seen.
>
> Is this needed? If the CMakeCache.txt file continues to be written,
> clients could just parse that file. If clients want to make changes
> (ie. cache editors), they can rewrite the file. Is that a problem? I
> assume it is, because CMake needs to reconfigure when it rereads it.
> In that case, the server should provide a way to report the contents,
> but also ways to modify it.

Yes, this is needed.

I do not want 3rd party code to interact with what is basically a file
internal to cmake.

And the syntax of that file is not as trivial as the comment at its
top claims it is. Just check how properties on values are encoded.

Best Regards,
Tobias
-- 

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] daemon-mode meeting last Tuesday

[Tobias Hunger]

Hi Rolf,

Am 23.06.2016 23:00 schrieb "Rolf Eike Beer" :
> What about just passing --server-fd= into it? That way the client
can set
> up whatever if wants to pass there and CMake has nothing to do with any
setup.
> And if one really wants to get messy one could pass a tty there.

Not sure whether that is even possible on all platforms we need.

Libuv (which the server is using) apparently has a cross-platform solution
for setting up a communication channel like the one we need, so I want to
give that a try.

Best Regards,
Tobias
-- 

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] daemon-mode meeting last Tuesday

[Tobias Hunger]

Hi Ben,

Am 23.06.2016 22:48 schrieb "Ben Boeckel" :
> cmake-oracle sounds reasonable for what it's doing to me.

I hope this thing will provide information more reliable than e.g. the
Oracle of Delphi in ancient Greece:-)

Best Regards,
Tobias
-- 

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] daemon-mode meeting last Tuesday

[Tobias Hunger]

Am 23.06.2016 22:46 schrieb "Brad King" <brad.k...@kitware.com>:
>
> On 06/23/2016 08:27 AM, Tobias Hunger wrote:
> Great!  Thanks for the detailed summary of the meeting and status of the
design.

You are welcome.



> >   * Some names could be improved. Suggestions welcome.
>
> We'll cover these in more detail during review.  The most important name
is
> the name of the feature, and IMO "daemon" is not an accurate description
of
> it (it is never re-parented to 'init' and has a lifetime tied to the
client).
> I think "server" would be better but am open to other suggestions.  Even
if
> it later really becomes a daemon the name "server" will still be
appropriate.

I'll create a task to rename it to "server" then.



> >   * Currently a reply (and error and all other messages in response to a
> > request) contain a "inReplyTo" with the type string from the request
> > triggering the reply.
> >
> > Stephen thinks that is not necessary and argues anything that is not
> > strictly necessary should not be in the first version of the
protocol.
> >
> > I like having this as it makes it helps to identify what a
reply/error is
> > related to. I often paste a whole string of requests into the
daemon and
> > if there is an error it is really easy to see how for things got.
>
> Would each type of query have a known type of response?  Shouldn't the
response
> objects have a type too?

It has a type: "reply" (or "error"). I so far use the inReplyTo field to
specify what the request a reply refers to. Stephen thinks that is not
necessary as there is always one request in flight and the client can just
figure things out without additional information.

> Also, doesn't the cookie allow the query/response
> pairs to be matched?

In theory yes. But a protocol should work without having to reply on
cookies.

A cookie is user data attached to an request. The idea is that e.g. an IDE
can run a request for some more details on some node in the project tree
view and pass some form of ID of the node the information is for along with
the query. That can simplify client code a lot.

> >   * Should we have a split between header (cookie/type/inReplyTo) and
data?
> >
> > Stephen suggested passing all data that is from/for the client in a
> > "body" attribute to make messages more uniform.
> >
> > I think that is just adding one more level into the JSON file for no
> > real benefit.
>
> I agree with Tobias that there is no reason to put the body fields in
> a sub-object.  However, I think the header fields should go in a
sub-object
> named by a "header" field.  That will isolate the header field names from
> the body fields (good for sorted views, future addition of headers, etc.).

The header currently is the type, inReplyTo and the cookie. I did not see
the need to separate those.

> >   * This is currently used to set sourcedirectory, builddirectory and
> > generator.
> >
> > These three should be passed in via the command line instead, again
> > to avoid trouble with users switching to different build
directories/etc.
> > while the daemon is running, which might trigger problems with state
> > cleanup, etc.
>
> Currently cmake-gui supports switching generators, build trees, etc., so
> there is some precedent for such switching within a single process.  If
> we have (re-)initialization bugs they should simply be fixed.

So you think we should keep that? I do not have an opinion here and need to
follow the advise of people more knowledgeable about CMake code than I am.

> >   * Figure out whether a PDB file is actually going to be build.
Currently
> > the PDB file is added to the list of artifacts whenever there is a
.lib
> > file, which is probably wrong. Brad: Do you have an idea how to
> > get this information?
>
> I'm not sure we have that information.  IIRC CMake only adds settings to
the
> generated build system to tell the tools where to put the .pdb and what to
> call it if it happens to be created.  We don't have install rules for them
> so there has never been a need to know whether they will actually be
created.
> Perhaps our format for the list of artifacts needs a way to indicate
whether
> an artifact is optionally present.

I think CMake should know what is generated and should not leave decisions
like that up to generators.

> >   2.8 buildsystem (return cmake files)
> >
> >   * Return a list of cmake files (CMakeLists.txt, etc.) in different
categories
> > (in source directory/in build directory/in the system).
> >
> >   * Stephen sugges

[cmake-developers] daemon-mode meeting last Tuesday

[Tobias Hunger]

)
  
  * This is currently used to set sourcedirectory, builddirectory and
generator.

These three should be passed in via the command line instead, again
to avoid trouble with users switching to different build directories/etc.
while the daemon is running, which might trigger problems with state
cleanup, etc.

  * The rest (trigger developer warnings, etc.) seems fine.
  
  * Generator/build- and sourcedirectory may not be set (even if reported
via globalSettings). Extragenerator can be set.

  
  2.4) configure (Trigger cmake to configure a builddirectory)
  
  * Fine, handles "-DSOMETHING=other", etc. via normal cmake commandline
parsing.

  TODO: Validate that it handles broken input with decent error reporting.

  
  2.5) generate
  
  * Rename this to "compute", which is what this actually triggers in cmake.

  
  2.6) project (Return project structure)
  
  * add backtrace information to targets
  
  * Rename to "codemodel" to make the use-case for the data more clear.
  
  * Focus on providing data for the use-case of feeding a code model.
  
  * Make the configuration the top-level, then report projects, targets and
files (in groups) beneath that. Currently projects are the top level, then
there is configurations, targets and files.

Switching this around should offer more flexibility to change cmake
internals going forward.

  * We do not want cmake internals to leak into the output. So do not report
cmake features, etc.

  * We try to minimize the assumptions of cmake internals in the implemention
to allow cmake room to innovate without breaking changes to this.

  * Policies should not be visible at this level and do not need to be exposed
to clients.

  FUTURE WORK:
  
  Stephen and I did not agree on how to handle other but similar use-cases that
  need similar information as to what is in this view and we will need to
  revisit this topic as new use-cases will get added in the future:
  
  Stephen prefers having special commands for each use-case, returning output
  tailored to that use-case.
  
  I would prefer having one command to gather the complete state of the
  project structure and then allow the user to limit what is returned from this
  command (e.g. only show one configuration/target/types of targets/etc. and
  options to filter out e.g. backtraces from the data that is returned).
  
  Stephens approach has the advantage that it is easier to use and more
  predictable what is returned. My approach allows client authors more
  flexibility as to which information they need without having to ask
  cmake developers to add a new command/change an existing one.
  
  But this is for the future: For the first iteration we want to concentrate on
  data relevant to feeding a code model.

  TODO:
  
  * Figure out whether a PDB file is actually going to be build. Currently
the PDB file is added to the list of artifacts whenever there is a .lib
file, which is probably wrong. Brad: Do you have an idea how to
get this information?


  2.7 cache (report contents of CMakeCache.txt file)
  
  * Review by other potential users would be appreciated, but no obvious
problems seen.

  
  2.8 buildsystem (return cmake files)
  
  * Return a list of cmake files (CMakeLists.txt, etc.) in different categories
(in source directory/in build directory/in the system).

  * Stephen suggested to rename this to "cmake_rerun_depends". I am not sure
that name is much better than what is currently used.



3.0 Features from Stephen's branch that need porting

   We only skimmed this, as many of his highlights need refactoring in cmake
   to land first.


   3.1 parse
   
   * This duplicates the parser and will need some refactoring.
   
   
Status Information:

I started to add some tasks to github to track what needs to be done before
proposing the daemon-mode branch for release. This can be viewed here:

https://github.com/hunger/CMake/issues

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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-mode

[Tobias Hunger]

Hi Brad,

Am 17.06.2016 22:09 schrieb "Brad King" :
> Then I applied the patches with some revisions:
>
>  cmGeneratorTarget: Adopt Fortran module directory generation
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49f10f0d
>
>  cmLocalGenerator: Add method to get Fortran-specific compiler flags
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5467e794
>
>  cmLocalGenerator: Adopt target compile flag generation
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3c488ce8
>
>  cmExtraSublimeTextGenerator: Use GetTargetCompileFlags
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=802b36fb
>
> These have been merged to `next` for testing.

Wonderful! Thanks for improving the patches

I'll rebase my branch on top of these as soon as they hit master.

Best Regards,
Tobias
-- 

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] daemon-mode: Infrastructure

[Tobias Hunger]

Hi Brad,
Am 17.06.2016 22:24 schrieb "Brad King" <brad.k...@kitware.com>:
>
> On 06/13/2016 08:00 PM, Tobias Hunger wrote:
> > * There will always be 1 client talking to a server.
> > * Client/Server communicate using JSON messages
>
> Yes.  IIRC it is using stdin/stdout (I haven't checked the code),
> so limiting to one client is implicit.

True. Still it does not hurt to state explicitly, especially considering
that I think of the stdin/out as an implementation detail. There is no
reason for the code not to switch to pipes or sockets for communication.

> In this case, is it actually a daemon?  It is not expected to outlive
> the client that started it.  Perhaps we should consider a different name.

I am bad at names:-)

Plus Stephen made quite a bit of PR for the CMake daemon idea.

> One possible problem with using stdin/stdout is that when CMake runs the
> configuration the project code can do things like execute_process that
> may share the stdout with the child process.  That may allow the child
> process to print content formatted to look like the protocol and trick
> the client.  Ideally all output handling would avoid printing things to
> stdout in server/daemon mode, but that may take some effort to achieve.

Yes, unexpected output on stdout could cause havok to the parser. So far
this worked well though, and the magic string before/after messages
prevented any unexpected interactions.

> > What do you think? Does this make sense?
>
> It sounds fine to me.  I'll state the caveat that I've had little
experience
> in maintaining versioned protocols like this though.  Hopefully others can
> review this too.

Yes, I hope other IDE developers will chime in at some point...

> On 06/14/2016 04:30 AM, Tobias Hunger wrote:
> > I think it would make perfect sense to ship the first cmake version with
> > included daemon-mode with a big, fat warning that the interfaces are not
> > finalized yet and will change in incompatible ways during the first
release
> > cycle (or maybe two:-).
>
> Yes.  Should we make the option to activate it different, and include
> "experimental" in its name?  I think the idea is that no clients should
> be released that depend on the experimental behavior in CMake.

I now added a patch that allows protocol versions to be marked as
experimental. These are only visible to clients that started "cmake -E
daemon --experimental".

The only existing protocol version is now marked experimental.

I think that makes it pretty clear what is experimental and what is not and
clients do not need to change (except for maybe dropping the --experimental
flag) to go to a stable interface once we are satisfied with the first
version.

Best Regards,
Tobias
-- 

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] codeblocks generator: Fix include directories being in unexpected order

[Tobias Hunger]

On Do, 2016-06-16 at 13:14 -0400, Brad King wrote:
> On 06/14/2016 11:52 AM, Tobias Hunger wrote:
> > https://github.com/hunger/CMake/commit/f190b069db2e430fd94b25e6287cd7fbc2866
> > 1e3
> > 
> > Is the same thing updated based on suggestions from Stephen.
> 
> Thanks, applied:
> 
>  cmExtraCodeBlocksGenerator: Do not shuffle include directories
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f190b069

Could this please go into 3.6?

This is the root cause of quite a few bug reports hitting Qt Creator bug tracker
right now, so I would love to see a fix out in the wild ASAP.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] daemon-mode: Project structure

[Tobias Hunger]

Hi Brad,

The project structure now lists an array of artifacts per target.

Best Regards,
Tobias

On Fri, Jun 10, 2016 at 5:48 PM, Brad King <brad.k...@kitware.com> wrote:
> On 06/10/2016 11:24 AM, Tobias Hunger wrote:
>>> The cmGeneratorTarget::GetFullName method will give you the name of the
>>> "main" file for a target.  Passing `implib = true` will give the DLL
>>> import library path on platforms where IsDLLPlatform returns true.
>>
>> I would have never found that!
>>
>> I'll change the code to list both the main artefact and the implib (if
>> applicable).
>
> Oops, I meant to point you at cmGeneratorTarget::GetFullPath to get the
> absolute paths with file names.
>
> -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
-- 

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] codeblocks generator: Fix include directories being in unexpected order

[Tobias Hunger]

On Di, 2016-06-14 at 15:21 +, Tobias Hunger wrote:
> Hello,
> 
> https://github.com/hunger/CMake/commit/a87e306fd03e7fae7409b16e4e586083822c6fe
> 8

https://github.com/hunger/CMake/commit/f190b069db2e430fd94b25e6287cd7fbc28661e3

Is the same thing updated based on suggestions from Stephen.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] codeblocks generator: Fix include directories being in unexpected order

[Tobias Hunger]

Hello,

https://github.com/hunger/CMake/commit/a87e306fd03e7fae7409b16e4e586083822c6fe8

has a fix to not put include directories into random order while trying to make
them unique.

Would that be applicable for the next release?

All Tests pass, with or without the patch.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] daemon-mode: Infrastructure

[Tobias Hunger]

PS: I think it would make perfect sense to ship the first cmake version with
included daemon-mode with a big, fat warning that the interfaces are not
finalized yet and will change in incompatible ways during the first release
cycle (or maybe two:-).

In my experience you only get the full feedback once the first release is out
and users can test it without building the code themselves. So this would
provide an opportunity to battle-harden all the daemon-mode APIs without
commiting us too early.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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-mode

[Tobias Hunger]

Hi Brad,

I just rebased this branch on top of current master and pushed it.
There were some conflicts.

Best Regards,
Tobias

On Mon, Jun 13, 2016 at 4:16 PM, Brad King <brad.k...@kitware.com> wrote:
> On 06/10/2016 12:31 PM, Tobias Hunger wrote:
>> I did try to do the changes you requested. The branch is here:
>>
>> https://github.com/hunger/CMake/commits/compileflags
>
> Thanks.  I'm about to go on travel but should hopefully be able to
> look at that again when I return.
>
> -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

[cmake-developers] daemon-mode: Infrastructure

[Tobias Hunger]

Hello,

one important piece of feedback from the daemon-mode: Project
structure discussion is that we need a policy to remove old code
again.

So I thought I should write up a bit about the infrastructure and
versioning support of the daemon-mode branch I am working on.

Basic Assumptions:
=

These are kind of hardcoded into the implementation and hard to change:

* There will always be 1 client talking to a server.
* Client/Server communicate using JSON messages


Implementation Overview:
==

Basically "daemon-mode" is implemented in the cmServer class. That
class uses libuv to receive requests from a client application and to
react on those requests. There is nothing that stops the cmServer from
also signalling the client about state changes (e.g. CMakeLists.txt
files being changed on disc), but that is not implemented at this
time.

In the constructor of cmServer you can define an arbitrary number of
cmProtocolVersion objects, each with a different version number
(major/minor numbers).

On first connect the cmServer will present the list of supported
protocol versions to the client and the client has to pick one of the
supported versions. The server will call Activate() (do your
initialization here;-) on the cmProtocolVersion object with the
selected version number.

>From that point on the cmProtocolVersion object is responsible for all
further interactions with the client. The cmServer will turn all
incoming messages into cmServerRequest objects and pass those to the
selected cmProtocolVersion's Process(...) method. This method will
return a cmServerResponse object (which can be created from the
cmServerRequest), which the cmServer will send on to the client.


Proposed Versioning:
===

The protocol version should start at version 1.0.

Any time new functionality is made available to daemon-mode, the minor
version number will be incremented. This includes new commands
becoming available as well as existing commands returning new keys in
addition to sending all the old keys.

Any time a incompatible change (e.g. removal of functionality,
restructuring of responses to requests, etc.) is made, the major
version is incremented and the minor is reset to 0. This includes
removing existing commands or changing the semantics/return types of
keys returned in response to any existing command.

If there was already a matching version bump, then there is no need to
do another till after the next release of cmake made. So two new
functionalities in one development cycle: Still only increase the
minor number by one.


Requesting Protocol Versions:
=

Let's assume we are writing a client for cmake-daemon as shipped in
cmake 4.2.4. At that time in the future the protocol version for the
cmake-daemon is at version 1.4 and that is what we test our
application with.

Our client should then request daemon mode to use protocol version 1.4
if available.

If that is not available, then it should just request the highest
minor number for version 1 and use that. That *should* be compatible
with version 1.4.

If there is no more protocol version 1.x supported the client should
abort or at least warn and continue with a higher major version
number.


Implementing new Protocol Versions:
==

* minor version bumps: Add a new cmServerProtocol class. Have its
Process(...) method implement the new functionality and then forward
to an instance of the previous version.

The sloppy approach would be to implement the the new functionality in
the previous versions class and just bump its number:-)

* major version bumps: At that point I would copy the existing code of
the previous version into a new cmServerProtocol class and then clean
it up. Then implement the changes in the new class.


Deprecating old Protocol Versions:


I would remove all the code for one major protocol version in one go.
That should be fairly straight forward to do (and the reason why I
suggested to just copy the code into a new major version of the
protocol) and should have little potential for damage.

In general I would suggest keeping old major versions around for at
least three cmake releases, but I would not put hard rules here: If
some old major version does not cost maintenance, then I'd suggest
keeping it longer.

On the other hand, if some changes require a major cmake version bump
(e.g. changing the cmake language in incompatible ways, etc.) so that
major user interaction is required during an update, then I would also
dump all old protocol versions immediately. Such fundamental changes
will probably also reflect deeply in the cmake internal structure,
which will also reflect in the daemon-mode protocol. I do not think it
makes sense to invest heavily into compatibility to old daemon-mode
clients in such an event.


What do you think? Does this make sense?

Best Regards,
Tobias
-- 

Powered by www.kitware.com

Please keep 

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

[Tobias Hunger]

Hi Stephen,

Am 11.06.2016 15:37 schrieb "Stephen Kelly" <steve...@gmail.com>:
>
> 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 added.
> >
>
> I think this is essential to the first version of the protocol.

Let's Start small and build from there. At this time this is not needed and
it is trivial to add when it becomes necessary.

Can we get something that is useful and working before going overboard?

> The central goal of the daemon is to make it easier to implement good
> support in existing tools and in new tools. In your branch you have a
> reset command in the protocol. I think that should be dropped because
> the daemon protocol should be designed such that it is never needed.

The Reset command is extremely handy as it allows to go back to a clean
slate to e.g. switch to a different project.

Without it you have to restart the daemon. I do not want to run one CMake
daemon per CMake project that is open in Creator. That can be a lot, and
once you store snapshots memory usage will increase quite a bit I assume:)

> > > Additionally, it appears to be
> > > redundant if you have a 'cookie'?
> >
> > No, cookies are to attach user data to requests and that is entirely
> > orthogonal to what inReplyTo does.
>
> Ok. Then I don't understand why clients need inReplyTo. I don't
> understand why it is not redundant. Clients know what cookie they
> specified in a request and they get the same cookie back, so they can
> check their cookie jar and get the same information as inReplyTo, right?

A cookie is used to attach user data to a request.

Discovering how messages relate to each other has to be possible without a
cookie.

> > > It is important that the daemon
> > > does not create a new claim of truth in this regard - the structure
> > from the
> > > daemon should be the same as the structure generated for those ide
> > projects.
> >
> > Why?
> >
> > I want the structure that *CMake* sees. What some unrelated program
> > generates out of that structure is irrelevant.
> >
>
> What CMake sees is what it generates for IDE buildsystems.
>
> Try taking a buildsystem of multiple directories and targets and putting
> project() commands at various positions - before/after add_subdirectory
> calls, in between targets, top of the file etc, and see what CMake does
> there.
>
> You might have an argument for *changing* what CMake does there, but you
> would need to state such a change explicitly. (and to do that you need
> to be aware of it in the first place)

I do not want to change anything here!

This mechanism works well, it is what the Codeblocks generator uses and it
also happens to be very close to how CMake operates. At least the concepts
map down to CMake object very naturally.

> This is part of the design work for the daemon because the behavior of
> the daemon should not be accidental in any way. While protocol
> versioning will make it possible to introduce new versions of the
> protocol, old versions of the protocol will need to remain, and that can
> affect the C++ code of CMake in bad ways, particularly if what is
> exposed in the protocol is 'wrong' in some way. Just look at CMake
> policies - the first ones were introduced a decade ago and there is no
> plan for removing them.

I see no problem there: You can always cut out old protocols if their
implementation hurts too much. That sucks for users that need the old
version, but it can be cleanly detected.

This is an fact better than working with the command line client right now,
which regularly introduces niggling small changes all over the place which
are much harder to detect.

> I emphasise the above just to make the points that:
>
> * Designing a protocol like this is hard (and not fast)

We have been discussing this for about two years now.

Due to the protocol versioning the implementation can be changed again
later. If the old version is not too different we can do that even without
breaking clients!

> * We should introduce something minimal, avoiding redundancy, because
> removing things is hard

I agree. That is why the current daemon is very much limited to dumping the
project structure. It is a strong foundation to go further than that.

> * The protocol should possibly expose a way to set policies so that they
> can be used to deprecate behaviors in a compatible way, as is done
> elsewhere in CMake

The policies applied elsewhere in CMake should already be expressed in th

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

[Tobias Hunger]

Hi Stephen,

Am 10.06.2016 20:53 schrieb "Stephen Kelly" :
> > [== CMake MetaMagic ==[
> > {
> > # Reply header:
> > "cookie":"",
> > "type":"reply"
> > "inReplyTo":"project",
>
> 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 added.

> The inReplyTo does not fit that model.

It does. A filesystem change would be "type":"signal" or something instead
and will not have a inReplyTo (as it was not generated in reply to
something.

> Additionally, it appears to be
> redundant if you have a 'cookie'?

No, cookies are to attach user data to requests and that is entirely
orthogonal to what inReplyTo does.

> >
> > # Data:
> > "projects":
>
> What you call 'projects' appear to be 'targets' in CMake vocabulary. Is
that
> correct? Note that a project is something different in CMake vocabulary
(see
> the project command).

Actually that is exactly what is returned here.

> Note also that in CMake, targets (libraries, executables etc) have a
project
> name.  Conceptualizing this as 'a project is a group of targets' doesn't
> work well because of how CMake deals with multiple project() commands and
> the VS and Xcode structures it generates. See
>
>  cmGlobalGenerator::FillProjectMap()
>
> and how the result of that method is used. It is important that the daemon
> does not create a new claim of truth in this regard - the structure from
the
> daemon should be the same as the structure generated for those ide
projects.

Why?

I want the structure that *CMake* sees. What some unrelated program
generates out of that structure is irrelevant.



> > Is this the information you need for IDE integration?
>
> You might be packing too much into one protocol verb. Try this on LLVM and
> VTK for example to see how much data it is. Perhaps then compare with the
> gradual approach in my branch.

CMake itself is way below 100KiB.

A typical developer machine should be able to handle several 10MiB of JSON
data just fine. So I do not expect a problem there.

> In my branch I have
>
> * `buildsystem` - Get the targets (name, type, project) and backtraces
> * `target_info` - Get buildsystem properties for a target
> * `file_info` - Get buildsystem properties for a file in a target

I know. I did not like that, so I did it differently.

Basically I do want the really important information in one go instead of
requesting a little bit, iterate over the data, request some more, ...

In the end that is a lots of needless round trips and you send more data
over the wire, too, with all the protocol overhead.

> Getting the backtraces (instead of the location) for targets is important
-

I am aware of the importance of backtraces, but I do not see any use case
where this information needs to be available at the point the project
structure is requested.

An IDE can for example request backtraces for a target when/if needed and
does not need it right away to set up a project tree and code model.

A tool to run a static analyzer over all C++ files in a project will not
need backtraces ever.

This is why that information is not contained in the project structure at
all. Yes, we need to provide a way to retrieve backtraces for targets (and
other symbols), but not here.



The biggest part of your mail is about the history of the patch set and how
to collaborate further.

My cmake-daemon branch on github documents how I got from your branch to
mine.

I basically copied the cmServer* files from that branch on top of a fresh
CMake checkout when I started the new branch, removing all the Process*
functions and wiring up the server again. There was no change outside the
cmServer* files apart from the wiring to start the daemon.

Then I proceeded to add the Process* methods and other functionality back
in.

I did that to make review simpler for *other* reviewers. I had not expected
you to chime in at all. Don't get me wrong: I appreciate you experience,
your patience and your reviews! I just had not expected it. The impression
I got talking to you before is that you do not have the resources to push
this functionality forward at this time. In fact that is the *only* reason
I stepped up for this task.

This is why I wonder how working through your branch is supposed to
function within the resource limits on your side?

I do not want for this work to vanish into some obscure github branch
somewhere for weeks and month -- as it did so far. The CMake daemon is too
cool a feature for that!

Best Regards,
Tobias
-- 

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: 

Re: [cmake-developers] CMake daemon-mode

[Tobias Hunger]

Hi Brad,

On Thu, Jun 9, 2016 at 7:57 PM, Brad King  wrote:
> On 06/09/2016 09:27 AM, Brad King wrote:
>>> https://github.com/hunger/CMake/commit/bc060a44b6b2c2281ffe99815163ba02ec835dd6
>> Good. I need to review that one more deeply but should be able to integrate 
>> it.
>
> I split out some incremental commits toward that:
>
>  cmCommonTargetGenerator: De-duplicate CMAKE_BUILD_TYPE lookup
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de4ee088
>
>  cmLocalGenerator: Adopt GetFrameworkFlags method
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70d3bf85
>
>  cmLocalGenerator: Move GetFrameworkFlags implementation to private helper
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9613b96
>
> Please rebase on that (at least once it is in master).
>
> For the main change, please also move over AddFortranFlags, perhaps
> becoming cmLocalGenerator::GetFortranFlags.  The result should be
> that cmCommonTargetGenerator::GetFlags moves into the new
> cmLocalGenerator::GetTargetCompileFlags method except for the caching.
> That will preserve flag order for GetFlags.
>
> For the Xcode part of the changes, we cannot use the full
> GetTargetCompileFlags.  The reason is that for Xcode some of the
> flags, like the architecture settings, become .pbxproj file properties
> instead of raw flags.  It may be simplest to just drop that part of
> the change for now.  Or, we need to factor out an intermediate helper
> that can be shared by GetTargetCompileFlags and Xcode.

I did try to do the changes you requested. The branch is here:

https://github.com/hunger/CMake/commits/compileflags



Some comments on the individual commits (and a direct link):



This moves the fortran module directory creation:

https://github.com/hunger/CMake/commit/eb417fef8bd1c91041a211899a2a7984aa75774d



Next patch moves the AddFortranFlags code. This will need some careful
review, as it removes a
path conversion that were present in the original code (in two
places). I could just not figure out how
to convert in the new place.

https://github.com/hunger/CMake/commit/2d5f6c673cc8a39f8590acfc23d4a6d5af8900a7



Then I add the cmLocalGenerator::GetTargetCompileFlags method I want.

https://github.com/hunger/CMake/commit/9be6beddfe2c2eac6b61d572ee3e5131b0f0b30e



Finally I convert the Sublime generator over to the new code:

https://github.com/hunger/CMake/commit/deb0793a243c266aee00d4f6e07685a5268f3dae



As I said, the second one will need some special care during the
review. I did run all unit tests with all patches applied, and all
pass on my system.

Best Regards,
Tobias
-- 

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] Questions about coding conventions

[Tobias Hunger]

On Fr, 2016-06-10 at 16:34 +0200, Daniel Pfeifer wrote:
> If used consistently, it indicates that you are dealing with a member.
> I personally prefer `this->` over `m_`. With semantic syntax
> highlighting you probably don't need either of them. But then again,
> you often look at code that does not have semantic highlighting (eg.
> inside diffs).

So you optimize for teletype terminals and punish everybody that has invested in
new stuff like screens with *color* in the last couple of decades:-/

/me is trapped in 1995!

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] daemon-mode: Project structure

[Tobias Hunger]

On Fr, 2016-06-10 at 10:41 -0400, Brad King wrote:
> On 06/10/2016 10:28 AM, Tobias Hunger wrote:
> > Any pointers on how to get to that information? Any example code that gets
> > the
> > artifact list?
> > 
> > I do not think this information is particularly worthwhile to add, but am
> > open
> > to change this.
> 
> An "artifactDirectory" field is not appropriate because there can be more
> than one artifact per target, and in different directories.  What is it
> that an IDE might want to do with this information?  If nothing, we could
> just drop it for now.

I need the path to executables that get built as well as directories that
libraries (dlls in windows) end up in, so that I can set up the environment for
the executables in such a way that they find their libraries.

> The cmGeneratorTarget::GetFullName method will give you the name of the
> "main" file for a target.  Passing `implib = true` will give the DLL
> import library path on platforms where IsDLLPlatform returns true.

I would have never found that!

I'll change the code to list both the main artefact and the implib (if
applicable).

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] daemon-mode: Project structure

[Tobias Hunger]

On Fr, 2016-06-10 at 10:06 -0400, Brad King wrote:
> On 06/09/2016 11:52 AM, Tobias Hunger wrote:
> >   [== CMake MetaMagic ==[
> 
> What is the purpose of this non-json wrapper in the content?
> Just part of the message protocol so that readers do not have
> to parse the json to know when the end of the message is reached
> (balanced with the start)?

At this time the daemon-mode accepts commands via stdin and responds via stdout.
The problem is that cmake will still happily send lots of output to stdout...
and in theory could even accept input from stdin. So Stephen added these CMake
MetaMagic around the JSON input/output.

It is pretty convenient for debugging and testing and we can always ask libuv to
communicate via a socket instead if that becomes necessary.

> I'd prefer a more descriptive name than "MetaMagic".

Please feel free to suggest whatever you prefer. I have no opinion on these
strings, as long as they are fixed:-)

> * What information to store about library build locations? Or maybe list
> > build
> >    artifacts instead?
> 
> I prefer the latter as I've mentioned elsewhere in the related threads.

Any pointers on how to get to that information? Any example code that gets the
artifact list?

I do not think this information is particularly worthwhile to add, but am open
to change this.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] Questions about coding conventions

[Tobias Hunger]

On Fr, 2016-06-10 at 15:30 +0200, Daniel Pfeifer wrote:
> Naming conventions: Classes are named  cmLikeThis. Member functions
> and member variables are named LikeThis. Local variables are named
> likeThis. Members are always accessed with `this->`. So far it is
> pretty consistent. But how to name free functions and macros? I have
> seen all kinds of variations.

May I asked why "this->" is used so often? I find it totally annoying to skip
this line noise all the time and I never encountered this convention before.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] cmCacheManager related changes

[Tobias Hunger]

Hi Brad,

I got some more changes to enable daemon-mode to access the full contents of the
CMakeCacheManager. With these patches and the daemon mode as of today Daniel
should be able to implement something like ccmake with daemon-mode only.

These patches are all concerned about accessing the properties that are set
on the cache values.

https://github.com/hunger/CMake/commit/b46f1feae7c2f1bd47b7d1848ce31d4edf505a1e

makes the list of defined properties accessible from the cmPropertyMap.

https://github.com/hunger/CMake/commit/a7bf58458172580e0aab865726b18341af142248

makes the list of defined properties accessible from the cmCacheEntry.

https://github.com/hunger/CMake/commit/0ff8cd2e862b52a0baf271b127945bed00f8db38

It kills an uninitialized cmCacheManager* in the cmake object and its getter.

https://github.com/hunger/CMake/commit/958c0bfd18f26a9d61d2a39ed826a7ce40fce35c

Adds an interface to cmState to retrieve the property list.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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-mode

[Tobias Hunger]

Hi Brad,

Am 09.06.2016 19:57 schrieb "Brad King" :
>
> On 06/09/2016 09:27 AM, Brad King wrote:
> >>
https://github.com/hunger/CMake/commit/bc060a44b6b2c2281ffe99815163ba02ec835dd6
> > Good. I need to review that one more deeply but should be able to
integrate it.
>
> I split out some incremental commits toward that:
>
>  cmCommonTargetGenerator: De-duplicate CMAKE_BUILD_TYPE lookup
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=de4ee088
>
>  cmLocalGenerator: Adopt GetFrameworkFlags method
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70d3bf85
>
>  cmLocalGenerator: Move GetFrameworkFlags implementation to private helper
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d9613b96
>
> Please rebase on that (at least once it is in master).

How long does it usually take to get something into master?

I do rebase rather often on top of master right anyway. I do want to stay
current as I hate running into merge conflicts after weeksof solitary work
in my little ivory tower of code:)

> For the main change, please also move over AddFortranFlags, perhaps
> becoming cmLocalGenerator::GetFortranFlags.  The result should be
> that cmCommonTargetGenerator::GetFlags moves into the new
> cmLocalGenerator::GetTargetCompileFlags method except for the caching.
> That will preserve flag order for GetFlags.

I will give that a try.

> For the Xcode part of the changes, we cannot use the full
> GetTargetCompileFlags.  The reason is that for Xcode some of the
> flags, like the architecture settings, become .pbxproj file properties
> instead of raw flags.  It may be simplest to just drop that part of
> the change for now.  Or, we need to factor out an intermediate helper
> that can be shared by GetTargetCompileFlags and Xcode.

I think I will just drop that part then. I do not have a Mac handy to test
anyway.

> 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] daemon-mode: Project structure

[Tobias Hunger]

Hello everybody,

Ok, so far I changed this:

 * sourceGroups got renamed to fileGroups
 * System include paths get reported
 * GLOBAL_TARGETs are no longer listed.
 
So this is what it looks right now:

  [== CMake MetaMagic ==[
{
  # Reply header:
  "cookie":"",
  "type":"reply",
  "inReplyTo":"project",

  # Project data:
  "projects":
  [
    {
      "name":"CMAKE_FORM",
      "sourceDirectory":"/home/code/src/cmake/Source/CursesDialog/form"
      "buildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/form",
      "configurations":
      [
        {
          "name":"",
          "targets":
          [
            {
              "artifactDirectory":"/tmp/cmake/Source/CursesDialog/form",
              "fileGroups":
              [
                {
                  "compileFlags":"  -std=gnu11",
                  "defines":
                  [ 
                    "SOMETHING=1",
                    "LIBARCHIVE_STATIC"
                  ],
                  "includePath":
                  [
                    { "path":"/tmp/cmake-build-test/Utilities" },
                    { "isSystem": true, "path":"/usr/include/something" },
                    # ;
                  ]
                  "lanugage":"C",
                  "sources":
                  [
                    "fld_arg.c",
                    # ;
                    "fty_regex.c"
                  ]
                }
              ],
              "fullName":"libcmForm.a",
              "linkerLanguage":"C",
              "name":"cmForm",
              "type":"STATIC_LIBRARY"
            }
          ]
        }
      ],
    }, # end of project
    # <snip, more (sub)projects>
  ] # end of projects list
} # end of message]== CMake MetaMagic ==]

Output size is ~77KiB for the cmake project in raw JSON format. This is much
smaller than before, due to the GLOBAL_TARGETs being gone.


Still open:

 * What information to store about library build locations? Or maybe list build
   artifacts instead?
 * Where are targtes going to get installed to?

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] daemon-mode: Project structure

[Tobias Hunger]

On Do, 2016-06-09 at 16:07 +0200, Milian Wolff wrote:
> On Donnerstag, 9. Juni 2016 13:27:26 CEST Tobias Hunger wrote:
> > On Do, 2016-06-09 at 08:43 -0400, Brad King wrote:
> > > >   "includePath":
> > > >   [
> > > > "/tmp/cmake-build-test/Utilities",
> > > > # 
> > > > "/home/code/src/cmake/Source/CursesDialog/form"
> > > >   ],
> > > 
> > > 
> > > Do we need some indication of whether each path is a "system" include
> > > dir?
> > 
> > Having that information would not hurt, but is not really critical IMHO.
> 
> I'm actually with Brad here. At least KDevelop's clang integration makes
> heavy 
> use of -isystem to silence warnings etc. from stuff outside the project. We 
> could hack that in ourselves by comparing an include path with the project 
> root, but a better approach would be to get the info directly from CMake 
> itself.

Ok, changed.

"includePath" is now reported like this:

"includePath":
[
  {
    "isSystem":false,
    "path":"/tmp/cmake-build-test/Utilities"
  },
  # 
]

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] daemon-mode: Project structure

[Tobias Hunger]

On Do, 2016-06-09 at 09:47 -0400, Brad King wrote:
> On 06/09/2016 09:27 AM, Tobias Hunger wrote:
> > I am using the output of cmState::GetTargetTypeName.
> 
> Okay.  We could consider excluding GLOBAL_TARGET targets from the
> output.  They never have source files and are nebulously defined.

OK, I'll remove GLOBAL_TARGETs completely from the output. You can already
limited the target types that are going to be listed, and I intended to use that
mechanism to suppress GLOBAL_TARGETs when using the daemon-mode from Qt Creator.

> > How can I get the directory a library/executable will be put into during the
> > build?
> 
> See the cmGeneratorTarget::GetFullPath.  That is one place that has
> been cleaned up to be consistent across generators.

I just renamed the target's "buildDirectory" to "artifactDirectory". It is
populated like this:
    const cmGeneratorTarget::OutputInfo* output =
  target->GetOutputInfo(config);
if (output) {
  result[ARTIFACT_DIRECTORY_KEY] = output->OutDir;
}

I assume that is the directory where (main?) artifacts will end up in?

Should I dump the other values of OutputInfo, too?

> > For libraries the directory should be enough -- that suffices to set up
> > LD_LIBRARY_PATH or whatever is needed for the system to look up libraries.
> > For
> > executables (which I need the full path of), the fullName combined with an
> > artifact directory is probably enough.
> 
> For shared libraries there can be two separate directories on Windows.
> The .lib and .dll parts can be in different directories.  I think it
> is simpler to enumerate the artifacts with some meta-data about the
> type of each one.  The clients can compute from that the directories
> or runtime path information that they need.
> 
> > I would also like to put the location after "make install"
> 
> The information is not associated with cmTarget or cmGeneratorTarget.
> Each target may have more than one install rule, so the destinations
> are associated with the install rules generated by the install()
> command.
> 
> See cmInstallTargetGenerator and cmExportInstallFileGenerator for
> some of that infrastructure.

I will look into that next.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] daemon-mode: Project structure

[Tobias Hunger]

On Do, 2016-06-09 at 08:43 -0400, Brad King wrote:
> On 06/09/2016 05:47 AM, Tobias Hunger wrote:
> > 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.
> 
> For reference, some design work on a format like this was discussed
> in another thread a couple years ago:
> 
>   Extracting target metadata, IDE integration,  2014-09-19
>   http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus
> =11000

I know, I partitcipated in that discussion.

> >   # Data:
> >   "projects":
> 
> To what does each "projects" entry correspond?

This is basically a list of (sub)projects. They are not really ordered, but
since they all have a sourceDirectory that should not be a problem.

> >   [
> > {
> >   "configurations":
> >   [
> > {
> >   "name":"",
> >   "targets":
> 
> Should "configurations" be an array or a map?  A map would guarantee at most
> one configuration of a given name.

An array is IMHO easier to handle. A hope cmake already guarantees that the
names of its configurations are unique, so I do not think this is an issue one
way or another.

> >   [
> > {
> >   "fullName":"test",
> >   "name":"test",
> >   "type":"GLOBAL_TARGET"
> 
> I've never liked the name "GLOBAL_TARGET" because it does not really represent
> what the type of target is.  I think we should avoid exposing the internal
> enum
> names through the protocol (we already do in the TYPE target property, but the
> GLOBAL_TARGET type is never available there).  Unfortunately I've never come
> up with a better name, so I'd welcome suggestions.  The target type is used
> for
> CMake-generated targets that get separately generated in each build
> (sub)directory,
> like "make install" and "make test".  Their effects are localized to each
> directory
> in generators that support that.

I am using the output of cmState::GetTargetTypeName. I do not want to map those
names to something else if I can avoid it:-)

> > },
> > # 
> > {
> >   "buildDirectory":"/tmp/cmake-build-
> > test/Source/CursesDialog/form",
> >   "fullName":"libcmForm.a",
> 
> The build directory and the location of the library file may not be the same.
> Also, there may be more than one artifact per target.  A .dll has its .lib
> import library.  A .so may have versioned symlinks.  This field could be
> an "artifacts" array or map.

How can I get the directory a library/executable will be put into during the
build?

For libraries the directory should be enough -- that suffices to set up
LD_LIBRARY_PATH or whatever is needed for the system to look up libraries. For
executables (which I need the full path of), the fullName combined with an
artifact directory is probably enough.

I would also like to put the location after "make install", but so far I could
not find how to get that.

> >   "linkerLanguage":"C",
> >   "name":"cmForm",
> >   # "sysroot": "/some/path", if set...
> >   "sourceGroups": # Just groups files with similar settings
> >   # together to save space
> 
> The name "source groups" already has a meaning in CMake.  If the goal is
> just to combine sources with the same settings, please use a different name.
> 
> >   [
> > {
> >   "compileFlags":"  -std=gnu11",
> 
> The format could use the same breakdown that CMake does internally to separate
> target-wide flags from per-source flags.  That would also save space, and it
> will be easy for clients to combine the flags.

That would force clients to figure out how to combine the two sets of flags.
Let's keep this knowledge inside cmake, please.

Per-file overrides are probably not as widely used that it makes sense to
optimize for that. At least the difference in output size was not remarkable
with any of the projects I experimented with.

> >   "defines":
> >   [
> > "CURL_STATICLIB",
> > # 
> > "LIBARCHIV

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

[Tobias Hunger]

Hi Milian,

great that you have found the time to look over this! It is greatly appreciated!

On Do, 2016-06-09 at 12:32 +0200, Milian Wolff wrote:
> > [== CMake MetaMagic ==[
> > {
> >   # Reply header:
> >   "cookie":"",
> >   "type":"reply"
> >   "inReplyTo":"project",
> >   
> >   # Data:
> >   "projects":
> >   [
> > {
> >   "configurations":
> >   [
> > {
> >   "name":"",
> 
> Can you enlighten me what these configurations are? Probably a CMake feature
> I 
> haven't used. Maybe it's for Windows to have release and debug builds in one 
> go? How would it look like there? 

Apparently you can have build systems that can produce debug/release/whatnot
builds in one one. In these systems you would get several entries here: One for
each of the build configurations you can build.

This seems to apply only to VisualStudio and XCode generators. All others should
have just one configuration.

> >   "targets":
> >   [
> > {
> >   "fullName":"test",
> >   "name":"test",
> >   "type":"GLOBAL_TARGET"
> > },
> 
> A nice-to-have would be a pointer to where the target got created, is that 
> feasible? That would allow an IDE to add a context menu to the target list to 
> jump to the CMakeLists.txt to edit the target.

Stephen's work has lots of debugging features. It should be straight forward to
figure out the location with those. So I am not sure it makes sense to add this
here. Users sometimes define their targets in ways that are way too challenging
to figure out with the little information available here (think macros and
whatnot).

> >   [
> > {
> >   "compileFlags":"  -std=gnu11",
> >   "defines":
> >   [
> > "CURL_STATICLIB",
> > # 
> > "LIBARCHIVE_STATIC"
> 
> Setters with values would then look like `FOO=1` I assume?

Yes, exactly.



> >   ] # end of tragets list
> > } # end of one configuration object
> >   ], # end of configurations list
> >   "currentBuildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/for
> > m",
> > "currentSourceDirectory":"/home/code/src/cmake/Source/CursesDialog/form",
> 
> why is this the "current" source director", shouldn't this be just 
> "sourceDirectory"? The project's source directory cannot change by fiddling 
> with the configuration after all, it's part of the source file structure? I 
> know that in CMake you have ${CMAKE_CURRENT_SOURCE_DIR}, but we don't need to 
> follow that naming for this purpose here, or?

Good point. I'll just use sourceDirectory and buildDirectory in the next push.

> > Is this the information you need for IDE integration?
> 
> I think so, yes. We get all targets and their defines and includes with 
> associated files. Additionally to what we where capably of before, we also
> get 
> the project structure, which is nice. And your format is way more efficient
> by 
> grouping sources with common include/define settings together, good choice.

Thanks!

> > Do you cmake developers feel comfortable to expose this information?
> > 
> > The total of the project data from the cmake project is ~102KiB of raw JSON
> > data.
> > 
> > What is not listed is the build system file list and the CMakeCache. I want
> > to keep these two separate: I can think of some use cases where that
> > information is not at all necessary:-)
> 
> What do you mean by "build system file list" - generated source files? Or 
> binary object files? Or CMakeLists.txt?

I want a list of all the CMakeLists.txt files (and .cmake files and .in files
and whatnot). All the files that would need watching to know when to ask the
user to re-run cmake again since something might have changed.

As an IDE you will want to list these files, too.

Right now this can be 

> Great work, thanks a lot!

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] daemon-mode: Project structure

[Tobias Hunger]

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 (with comments;-):

[== CMake MetaMagic ==[
{
  # Reply header:
  "cookie":"",
  "type":"reply"
  "inReplyTo":"project",
  
  # Data:
  "projects":
  [
{
  "configurations":
  [
{
  "name":"",
  "targets":
  [
{
  "fullName":"test",
  "name":"test",
  "type":"GLOBAL_TARGET"
},
            # 
{
  "buildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/form",
  "fullName":"libcmForm.a",
  "linkerLanguage":"C",
  "name":"cmForm",
  # "sysroot": "/some/path", if set...
  "sourceGroups": # Just groups files with similar settings
                              # together to save space
  [
{
  "compileFlags":"  -std=gnu11",
  "defines":
  [
"CURL_STATICLIB",
                    # 
"LIBARCHIVE_STATIC"
  ],
  "includePath":
  [
"/tmp/cmake-build-test/Utilities",
                    # 
"/home/code/src/cmake/Source/CursesDialog/form"
  ],
  "lanugage":"C",
  "sources":
  [
"fld_arg.c",
                    # 
"fty_regex.c"
  ]
}
  ],
  "type":"STATIC_LIBRARY"
},
            # 
{
  "fullName":"install",
  "name":"install",
  "type":"GLOBAL_TARGET"
}
  ] # end of tragets list
} # end of one configuration object
  ], # end of configurations list
  "currentBuildDirectory":"/tmp/cmake-build-test/Source/CursesDialog/form",
  "currentSourceDirectory":"/home/code/src/cmake/Source/CursesDialog/form",
  "name":"CMAKE_FORM"
}, # end of one project object
    # 
  ] # end of project list
}
]== CMake MetaMagic ==]

Is this the information you need for IDE integration?

Do you cmake developers feel comfortable to expose this information?

The total of the project data from the cmake project is ~102KiB of raw JSON
data.

What is not listed is the build system file list and the CMakeCache. I want to
keep these two separate: I can think of some use cases where that information is
not at all necessary:-)

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] Review request: extract-cmMessenger branch

[Tobias Hunger]

On Do, 2016-06-09 at 10:18 +0200, Stephen Kelly wrote:
> > What I would like to have, is separate subclasses for gcc-style and
> > msvc-style messages. In gcc-style, messages look like this:
> > 
> > :row:column: error: 
> > 
> > In msvc-style, messages look like this:
> > 
> > (row,column): error: 
> > 
> > This would make it easier to jump to the location in IDEs (and
> > powerful editors).

I would really prefer cmake to decide on one format and to stick with that
*consistently* for all messages.

Preferably with some prefix so that the IDE can actually find out that the
message is from cmake if they get dumped to stdout/stderr. Such a prefix is of
course not important when messages are reported via an API of some kind.

> Hmm, some existing clients (KDevelop) parse messages in the form they
> are already in. They would break if all message formats were changed
> substantially. Having the above behavior be dependent on some command
> line option or environment variable wouldn't be great either.

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!

Here are some of the different styles used to report various issues in cmake:

CMake Error: Error in cmake code at
/test/path/CMakeLists.txt:9:
Parse error.  Expected "(", got newline with text "


CMake Error at src/1/app/CMakeLists.txt:70 (add_custom_target):
  Cannot find source file:

    unknownFile.qml

  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp


CMake Error at src/1/CMakeLists.txt:8 (add_subdirectory):
  add_subdirectory given source "app1" which is not an existing directory.


CMake Error: Error required internal CMake variable not set, cmake may be not be
built correctly.
Missing variable is:
CMAKE_MAKE_PROGRAM


Syntax Warning in cmake code at
/test/path/CMakeLists.txt:9:15
Argument not separated from preceding token by whitespace.



Multi line messages are especially hard to parse correctly with the inconsistent
reporting currently done by cmake.

> The impact of this would need to be assessed.

Almost anything will be an improvement over the status quo!

If you were to unify on e.g.

CMake Error at FILE:LINE (OPTIONAL_EXTRA_INFO):
  MULTILINE_MESSAGE_WITH_INDENT_ENDING_IN_TWO_NEWLINES

then you will probably hit existing code paths in IDEs.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] cmLocalGenerator::GetTargetFlags

[Tobias Hunger]

Hi everybody,

what use is the "flags" out-parameter in cmLocalGenerator::GetTargetFlags? It is
only ever set for targets of type EXECUTABLE and is filled based on the *linker
language* of the target.

I really do not see any use for this information, and indeed the flag seems
unused in the cmake code base, except for the Ninja generator, where that may or
may not make sense (probably not).

Can the flag get removed altogether and the method get renamed to
GetTargetLinkerFlags? Maybe it could return the linker language instead, that is
a piece of data that is more important in its context IMHO.

While discussing this method: How about moving the method to cmTargetGenerator?
That would get rid of the target parameter. That is where I would actually look
for information on targets.



Which brings me back to my original question: How can I find the compiler flags
in use for a cmSourceFile/cmGeneratorTarget? The only place that I found that
seems to do what I want is cmCommonTargetGenerator::GetFlags. Or is that
concerned about cmake internal flags that need to get mapped to compiler flags
later? Is there another copy of that code in a place more convenient to use or
do I need to create that?

cmCommonTargetGenerator does caching of results. Should this be also done for
cmLocalGenerator::GetTargetFlags, etc?

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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-mode

[Tobias Hunger]

Hi Brad,

Am 07.06.2016 19:23 schrieb "Brad King" :
> If it doesn't conflict with 'master' too much I can take it directly.

It should not. I regularly rebase my branch on top of master.

> I've cherry-picked 124f8295bee0c228b79a5cf38f0b2581be308118 and merged
> to 'next' for testing:
>
>  cmLocalGenerator: Pass configuration to GetTargetFlags
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe0d2241

Great, thanks!

I would love to keep my patch set as small as possible:)

Best Regards,
Tobias
-- 

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-mode

[Tobias Hunger]

Hi Brad,

sorry for the empty mail, my phone acted up:-)

Am 07.06.2016 16:48 schrieb "Brad King" <brad.k...@kitware.com>:
>
> On 06/07/2016 10:42 AM, Tobias Hunger wrote:
> > On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote:
> >> We should be able to refactor things to share the flags computation.
> >> Methods like
> >>
> >>   cmLocalGenerator::GetTargetFlags
> >
> > Does this patch here make sense:
> >
> >
https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118
> >
> > It passes the configuration to GetTargetFlags instead of forcing it to
the build
> > type. Since I may end up with different configurations in the project
structure,
> > I think this is necessary.
>
> Yes.  Previously that method was only called in single-configuration
> generators so it could look up the CMAKE_BUILD_TYPE directly.  In
> multi-config generators that variable is meaningless and instead they
> iterate over CMAKE_CONFIGURATION_TYPES.
>
> When you have a few such independent refactoring changes done
> we can look at integrating them immediately to avoid holding
> them externally in your daemon topic for too long.

Can you take that patch from github or do you want them sent here?

Best Regards,
Tobias
-- 

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-mode

[Tobias Hunger]

Hi
Am 07.06.2016 16:48 schrieb "Brad King" <brad.k...@kitware.com>:

> On 06/07/2016 10:42 AM, Tobias Hunger wrote:
> > On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote:
> >> We should be able to refactor things to share the flags computation.
> >> Methods like
> >>
> >>   cmLocalGenerator::GetTargetFlags
> >
> > Does this patch here make sense:
> >
> >
> https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118
> >
> > It passes the configuration to GetTargetFlags instead of forcing it to
> the build
> > type. Since I may end up with different configurations in the project
> structure,
> > I think this is necessary.
>
> Yes.  Previously that method was only called in single-configuration
> generators so it could look up the CMAKE_BUILD_TYPE directly.  In
> multi-config generators that variable is meaningless and instead they
> iterate over CMAKE_CONFIGURATION_TYPES.
>
> When you have a few such independent refactoring changes done
> we can look at integrating them immediately to avoid holding
> them externally in your daemon topic for too long.
>
> 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
>
-- 

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-mode

[Tobias Hunger]

On Mo, 2016-06-06 at 13:24 -0400, Brad King wrote:
> We should be able to refactor things to share the flags computation.
> Methods like
> 
>   cmLocalGenerator::GetTargetFlags

Does this patch here make sense:

https://github.com/hunger/CMake/commit/124f8295bee0c228b79a5cf38f0b2581be308118

It passes the configuration to GetTargetFlags instead of forcing it to the build
type. Since I may end up with different configurations in the project structure,
I think this is necessary.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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-mode

[Tobias Hunger]

Hi Brad!

On Mon, Jun 6, 2016 at 7:24 PM, Brad King  wrote:


>> A big chunk of Stephen's work has not even landed in my branch yet. Since 
>> cmake
>> reformated all the source in the meantime it is a bit tedious to apply 
>> patches
>> from his tree and I have simply not yet needed the changes as I did not 
>> venture
>> where he went yet.
>
> See commit v3.6.0-rc1~54^2~2 (82df6deaaf).  Its commit message explains
> how to rebase across the style transition.  If you rebase the original
> "cmake-daemon" branch on that then we can rewrite the style to make
> cherry-picking later easier.

Thanks, that might prove helpful.

So far i basically picked the same sha, that worked surprisingly well.

>> At this time I think I will need to duplicate a chunk of code from one of the
>> generators to find the flags. Is that really necessary? If so: Which 
>> generator
>> should I copy the code from?
>
> We should be able to refactor things to share the flags computation.
> Methods like
>
>   cmLocalGenerator::GetTargetFlags
>   cmLocalGenerator::GetIncludeDirectories
>
> are meant to be used across multiple generators.  Due to historical
> evolution in generator design not everything has been refactored to
> cleanly share such infrastructure across all generators.  Stephen made
> a lot of progress on that front, but there is still a way to go IIRC.

So is that the complete picture?

You can override compile time flags on a per-file basis, based on the
code I ran across in the ninja generator:-) Do I still need to add
those per-source-file flags somehow?

Best Regards,
Tobias
-- 

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-mode

[Tobias Hunger]

Hi Daniel,

On Tue, Jun 7, 2016 at 11:27 AM, Daniel Pfeifer <dan...@pfeifer-mail.de> wrote:
> On Mon, Jun 6, 2016 at 5:39 PM, Tobias Hunger <tobias.hun...@qt.io> wrote:
>> Please help to support your use-cases.
>
> A while ago I wrote a graphical cache editor in GTK:
> https://github.com/purpleKarrot/cmake-gtk
> The tool reads the cache and provides a graphical view to modify it.
> It can then write the cache, run cmake, and read it back.
>
> I wanted to see how close we can get to ccmake or cmake-gui without
> linking against CMakeLib.
>
> Here is what I was *unable* to achieve:
> * Separating Configure from Generate (two buttons).
> * Progress bar.
>
> Quite a short list, right?
> If we have a daemon mode that provides this information (as your
> implementation already does), we could let ccmake and cmake-gui use
> the daemon instead of linking against CMakeLib.

If the daemon can expose the right information, then you could even be
able to write a generator in e.g. python;-)

Best Regards,
Tobias
-- 

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] CMake daemon-mode

[Tobias Hunger]

 for generators

* Get CMakeCache via the daemon (after configure?)

* Get build system files from the daemon (after configure?)

* Get missing information on the project:
   * Defines
   * Compiler flags
   * Information on linkage of targets

* Group similar sources to shorten the output

* Support cmake --build via the daemon (optional?)

* Support cmake code completion

* Support cmake debugging



Help needed:
===

Please help to support your use-cases.

Please report what information you would like to have available from your cmake
projects via daemon-mode.

Patches are of course welcome at any time!

Any help in getting any interesting information out of cmake is highly
appreciated, too.

At this time I think I will need to duplicate a chunk of code from one of the
generators to find the flags. Is that really necessary? If so: Which generator
should I copy the code from?

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] Some trivial patches

[Tobias Hunger]

On Mi, 2016-06-01 at 11:18 -0400, Brad King wrote:
> On 06/01/2016 05:04 AM, Tobias Hunger wrote:
> > Attached you will find a couple of really small changes that add const to a
> > method and fix a couple of typos in comments. Trivial stuff.
> 
> Thanks.  I've applied the changes:
> 
>  cmSearchPath: Fix typo in comment
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=814e774e
> 
>  cmSourceFileLocation: Fix typo in comment
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bd4fef64
> 
>  cmGlobalGenerator: Make IsMultiConfig() const
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2175e5bf
> 
> > This is mostly to figure out how to contribute code:-)
> 
> Good job.  For large changes (e.g. cmake-daemon work) feel free
> to publish your branch somewhere and post a link here.  For most
> changes please post here.

Why did the typo fixes end up in the master branch and the const fix in the next
branch?

Do I need to do something to get it from next to master at some point?

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] Some trivial patches

[Tobias Hunger]

Hi CMake Developers!

Attached you will find a couple of really small changes that add const to a
method and fix a couple of typos in comments. Trivial stuff.

This is mostly to figure out how to contribute code:-)

Is this the preferred way you want your patches? Or do I need to inline
them somehow?

How can I create an account in the bug tracker?

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
From 2e3d372dd5026a257cd11badd87dbfff7255851d Mon Sep 17 00:00:00 2001
From: Tobias Hunger <tobias.hun...@qt.io>
Date: Tue, 31 May 2016 13:53:19 +0200
Subject: [PATCH 01/11] cmGlobalGenerator: Make IsMultiConfig() const

---
 Source/cmGlobalGenerator.h | 2 +-
 Source/cmGlobalVisualStudioGenerator.h | 2 +-
 Source/cmGlobalXCodeGenerator.cxx  | 2 +-
 Source/cmGlobalXCodeGenerator.h| 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/Source/cmGlobalGenerator.h b/Source/cmGlobalGenerator.h
index 2575911..68ff042 100644
--- a/Source/cmGlobalGenerator.h
+++ b/Source/cmGlobalGenerator.h
@@ -319,7 +319,7 @@ public:
 
   /** Return true if the generated build tree may contain multiple builds.
   i.e. "Can I build Debug and Release in the same tree?" */
-  virtual bool IsMultiConfig() { return false; }
+  virtual bool IsMultiConfig() const { return false; }
 
   std::string GetSharedLibFlagsForLanguage(std::string const& lang) const;
 
diff --git a/Source/cmGlobalVisualStudioGenerator.h b/Source/cmGlobalVisualStudioGenerator.h
index fb2cdbd..1d456ff 100644
--- a/Source/cmGlobalVisualStudioGenerator.h
+++ b/Source/cmGlobalVisualStudioGenerator.h
@@ -85,7 +85,7 @@ public:
 
   /** Return true if the generated build tree may contain multiple builds.
   i.e. "Can I build Debug and Release in the same tree?" */
-  virtual bool IsMultiConfig() { return true; }
+  virtual bool IsMultiConfig() const { return true; }
 
   /** Return true if building for Windows CE */
   virtual bool TargetsWindowsCE() const { return false; }
diff --git a/Source/cmGlobalXCodeGenerator.cxx b/Source/cmGlobalXCodeGenerator.cxx
index 6628cfc..b666594 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -3437,7 +3437,7 @@ std::string cmGlobalXCodeGenerator::ComputeInfoPListLocation(
 
 // Return true if the generated build tree may contain multiple builds.
 // i.e. "Can I build Debug and Release in the same tree?"
-bool cmGlobalXCodeGenerator::IsMultiConfig()
+bool cmGlobalXCodeGenerator::IsMultiConfig() const
 {
   // Old Xcode 1.5 is single config:
   if (this->XcodeVersion == 15) {
diff --git a/Source/cmGlobalXCodeGenerator.h b/Source/cmGlobalXCodeGenerator.h
index 2ca4c19..0485d4f 100644
--- a/Source/cmGlobalXCodeGenerator.h
+++ b/Source/cmGlobalXCodeGenerator.h
@@ -79,7 +79,7 @@ public:
 
   /** Return true if the generated build tree may contain multiple builds.
   i.e. "Can I build Debug and Release in the same tree?" */
-  virtual bool IsMultiConfig();
+  virtual bool IsMultiConfig() const;
 
   virtual bool SetGeneratorToolset(std::string const& ts, cmMakefile* mf);
   void AppendFlag(std::string& flags, std::string const& flag);
-- 
2.8.3

From 122c333c7820fd245a7a04851e4ac29cf58573a9 Mon Sep 17 00:00:00 2001
From: Tobias Hunger <tobias.hun...@qt.io>
Date: Tue, 31 May 2016 17:15:22 +0200
Subject: [PATCH 02/11] Fix typo

---
 Source/cmSearchPath.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/cmSearchPath.h b/Source/cmSearchPath.h
index 4b37a3a..835196f 100644
--- a/Source/cmSearchPath.h
+++ b/Source/cmSearchPath.h
@@ -26,7 +26,7 @@ class cmSearchPath
 {
 public:
   // cmSearchPath must be initialized from a valid pointer.  The only reason
-  // for teh default is to allow it to be easily used in stl containers.
+  // for the default is to allow it to be easily used in stl containers.
   // Attempting to initialize with a NULL value will fail an assertion
   cmSearchPath(cmFindCommon* findCmd = 0);
   ~cmSearchPath();
-- 
2.8.3

From dfc0409147b6bb07e95226e2dd56b001f2cc6dc8 Mon Sep 17 00:00:00 2001
From: Tobias Hunger <tobias.hun...@qt.io>
Date: Tue, 31 May 2016 17:15:56 +0200
Subject: [PATCH 03/11] Fix typo

---
 Source/cmSourceFileLocation.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Source/cmSourceFileLocation.h b/Source/cmSourceFileLocation.h
index af3651a..7989173 100644
--- a/Source/cmSourceFileLocation.h
+++ b/Source/cmSourceFileLocation.h
@@ -39,7 +39,7 @@ public:
   cmSourceFileLocation& operator=(const cmSourceFileLocation& loc);
 
   /**
-   * Return whether the givne source file location could refers to the
+   * Return whether the given source file location cou

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

[Tobias Hunger]

Am 24.03.2016 16:13 schrieb "Aleix Pol" :
> Hey,
> I'll be going to Berlin the weekend of the 14th May (Board meeting,
> I'll be busy during the weekend).
>
> Would it make sense for me to book one day before/after to meet and
> hack on this?

Hey Aleix,

I did already do some work on that front, trying to make the JSON API more
complete, less prone to sudden aborts (there used to be asserts that could
be triggered by user input), more consistent, and with better test
coverage. See my fork on github for details.

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 code.

Currently you (Aleix), Domminik and me seem to be the only people that want
this daemon, so I guess it would make sense for us to sit together and
decide what we want, whether we can maintain it together (or where we can
get help) and then hack into that direction.

Best Regards,
Tobias
-- 

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] [Qt-creator] CMake daemon for user tools

[Tobias Hunger]

Am 22.02.2016 23:14 schrieb "Stephen Kelly" :
> If anyone can get me a working java environment and a way to
asynchronously
> write stdin/stdout on long-running processes, I can write a plugin for
> eclipse which would be independent of cevelop afaict.
>
> Do you know enough java to help get started on that?

Can we please focus on getting this ready for inclusion into CMake first?
And fill in the missing pieces while doing that (e.g. find compile flags)?

It has so much potential, but right now it can not provide all the
information needed to feed a serious C++ code model! IMHO that needs to be
fixed first, before running of and plastering the world with more demos.
The ones you have are impressive enough already, now we need something that
is actually useful for real use.

Best Regards,
Tobias
-- 

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] [Qt-creator] CMake daemon for user tools

[Tobias Hunger]

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 probably get
a room in our office though (in Berlin).

> 2. Reading about this deamon approach, rtags comes to my mind: rtags

I personally do not consider rtags to be very interesting for my use-cases.
But I am the wrong person for that topic anyway.

> Given this background, I can see a lot of benefits in a cmake deamon
> that provides all sorts of infos...

So do I.

I did a bit of hacking on a fork of Stephen's code (
https://github.com/hunger/CMake/tree/cmake-daemon) where I added some
protocol improvements (more unified JSON messages going back and forth,
consistent error reporting, consistent progress reporting, more unit tests,
etc.). No new functionality, just a bit of polish here and there.

Best Regards,
Tobias
-- 

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 blog

[Tobias Hunger]

Hi Klaim,

I spent the WE to improve the unit tests in my fork of Stephen's
cmake-daemon (which got broken when I added some basic protocol features
earlier in the same fork).

I could use some help in this task that does not involve C++ coding:-)

Best Regards,
Tobias
Am 14.02.2016 12:58 schrieb "Klaim - Joël Lamotte" <mjkl...@gmail.com>:

> I'm surprised too that there isn't more feedback around here.
> This seems to be a marjor potential improvement and definitely necessary
> if CMake need to be usable in the coming years.
>
> On 10 February 2016 at 09:42, Tobias Hunger <tobias.hun...@gmail.com>
> wrote:
>
>> Hey, I did send a MR on github:-)
>>
>> But I agree, I had also hoped for more active participation.
>>
>> Best Regards,
>> Tobias
>>
>> On Wed, Feb 10, 2016 at 12:07 AM, Stephen Kelly <steve...@gmail.com>
>> wrote:
>> > 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 any of this is quite disappointing.
>> >
>> > --
>> >
>> > 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
>> --
>>
>> 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
>>
>
>
-- 

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] [PATCH]: Fix compiler warnings (clang from trunk)

[Tobias Hunger]

Just a small patch to fix a couple of compiler warnings that drove me crazy.
From 82f8ccb9afe7b07d42a772025498bb63f42f296c Mon Sep 17 00:00:00 2001
From: Tobias Hunger <tobias.hun...@gmail.com>
Date: Thu, 11 Feb 2016 17:47:42 +0100
Subject: [PATCH 01/43] cmListFileCache: Fix warnings during build

Fix warning about inconsistent use of class/struct in 
cmListFileCache.
---
 Source/cmListFileCache.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Source/cmListFileCache.h b/Source/cmListFileCache.h
index 03e0abe..4d3055f 100644
--- a/Source/cmListFileCache.h
+++ b/Source/cmListFileCache.h
@@ -58,8 +58,9 @@ struct cmListFileArgument
   long Line;
 };
 
-struct cmListFileContext
+class cmListFileContext
 {
+public:
   std::string Name;
   std::string FilePath;
   long Line;
-- 
2.7.1

-- 

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

[Tobias Hunger]

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
tests configured in the CMakeLists.txt? The builddirectory does not
contain a Tests/Server directory to run make test in:-/

Best Regards,
Tobias


On Wed, Feb 10, 2016 at 12:44 AM, Stephen Kelly  wrote:
> 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 made a pull request there. Rather than review it there, I will review
> it here for visibility.
>
>  https://github.com/steveire/CMake/pull/2
>
> The branch is quite it hard to review, or even to see the particular
> changes, due to large commits and diff noise. If the Daemon reaches a level
> of completeness that it could be upstreamed (See
>
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15740
>
> ) then these commits (including all of my commits on the branch) would have
> to be rewritten, split, made reviewable etc making heavy use of `rebase -i`.
>
> In a way, we don't have to do that now, but I'm also not very enthusiastic
> about making the `cmake-daemon` branch commits unreadable. I would add your
> commits to the branch if they we split and in the appropriate place (eg,
> with the cmServerProtocol0_1 change early in the cmake-daemon branch).
>
> The changes in your branch are good and useful to more than just QtCreator.
>
> Things that I like in your branch:
>
> * Explicit cmServerRequest and cmServerResponse APIs, which enforce the type
> and cookie consistency.
> * Returning cmServerResponse objects from the cmServerProtocol instead of
> invoking the server from the cmServerProtocol.
> * A way to version the protocol in a future-proof way with C++ classes.
> * Implementation of daemon and protocol error messaging infrastructure.
> (Reporting errors from cmake code requires other refactoring:
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=15636)
>
> So I think that is progress!
>
> Thanks,
>
> Steve.
>
>
>
> --
>
> 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
-- 

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

[Tobias Hunger]

Hi Stephen,

I will then continue down that road.

Next steps are a way to consistently report progress as well as being
able to have several protocol versions at the same time and have a
client pick one.

I will just put them atop my current branch, as that is going to need
basically the same amount of retro-active integration into similar
places as the current changes.

I am not keen on doing that twice:-)

Best Regards,
Tobias

On Wed, Feb 10, 2016 at 12:44 AM, Stephen Kelly  wrote:
> 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 made a pull request there. Rather than review it there, I will review
> it here for visibility.
>
>  https://github.com/steveire/CMake/pull/2
>
> The branch is quite it hard to review, or even to see the particular
> changes, due to large commits and diff noise. If the Daemon reaches a level
> of completeness that it could be upstreamed (See
>
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15740
>
> ) then these commits (including all of my commits on the branch) would have
> to be rewritten, split, made reviewable etc making heavy use of `rebase -i`.
>
> In a way, we don't have to do that now, but I'm also not very enthusiastic
> about making the `cmake-daemon` branch commits unreadable. I would add your
> commits to the branch if they we split and in the appropriate place (eg,
> with the cmServerProtocol0_1 change early in the cmake-daemon branch).
>
> The changes in your branch are good and useful to more than just QtCreator.
>
> Things that I like in your branch:
>
> * Explicit cmServerRequest and cmServerResponse APIs, which enforce the type
> and cookie consistency.
> * Returning cmServerResponse objects from the cmServerProtocol instead of
> invoking the server from the cmServerProtocol.
> * A way to version the protocol in a future-proof way with C++ classes.
> * Implementation of daemon and protocol error messaging infrastructure.
> (Reporting errors from cmake code requires other refactoring:
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=15636)
>
> So I think that is progress!
>
> Thanks,
>
> Steve.
>
>
>
> --
>
> 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
-- 

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

[Tobias Hunger]

Hi Stephen,

thanks for that information! Now I can finally fix the tests again
(and add a couple for the error cases
my branch handles;-).

I did play some more and implemented support for consistent progress
reporting and multiple protocol versions now in my branch at

https://github.com/hunger/CMake/tree/cmake-daemon

This unfortunately resulted in the interaction with the daemon changing a bit:-(

Upon start the daemon now sends:
{"supportedProtocolVersions":[{"major":0,"minor":1}],"type":"hello"}

You need to reply with something along the lines off:
{"type":"handshake", "protocolVersion": { "major": 0 }}

Daemon will respond with:
{"cookie":"","inResponseTo":"handshake","type":"reply"}

and listen for commands.

"version" will work at this point, but you need to do:

{"type":"initialize", "buildDirectory":"/some/build/dir"}

to trigger the actual parsing of data.

Afterwards all the usual commands are available as before.

I did not yet update the tests with this change, so I did not create a MR yet.

I also want to do some small (but intrusive) changes to how
cmServerResponse objects are created.

Best Regards,
Tobias
-- 

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 mode protocol

[Tobias Hunger]

Hi Stephen,

I think what I suggested so far is covered by the first way of
interaction covered in
http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411 .

I am just proposing something that is convenient for me to use.

On Sat, Jan 16, 2016 at 12:26 PM, Stephen Kelly  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 that cmake do that instead
>>> of leaving it for clients to do?
>>
>> It is doable. I just do not see why this should be necessary.
>
> I'm aiming to first design as much as possible of a 'minimal viable
> protocol' as a first step. Given the above I think your ideas of running the
> daemon with no build dir are not 'minimal' and I'm convinced they're not
> viable.

I am thinking about the simplest possible use-case I can think of
right now: User gets sources from a project somewhere and wants to
build those.

What is entirely unclear to me with your current implementation is how
do I get from "sources are checked out in $DIR" to "I have a $BUILD
that I can use to start the daemon"?

Then I also do not see how I can support a user switching between two
build directories. Do I need to close down one daemon and start
another?

> Someone would have to prototype the ideas, but I don't think that's a good
> use of time or energy right now (mostly because I think they're not viable).
>
> I recommend focussing on the tasks in my OP:
>
>  http://thread.gmane.org/gmane.comp.lib.qt.creator/11794

That list is so full of cmake internals that it is basically
meaningless to me. Sorry.

>>> Richer information about some semantics like 'task' and 'busy state'
>>> could also be provided in a similar way I expect, assuming those could be
>> defined.
>>
>> This is some basic functionality that we should get right soon, as this
>> can influence how long-running tasks need to be designed.
>
> Yes. Perhaps you can expand on what 'tasks' and 'busy state' you have in
> mind. Particularly if you can relate them to what is already in my github
> branch.

"task" is just some Id to identify what the daemon is currently doing.
"state" is just some indication of whether the daemon thinks it is
busy with something or not. In "idle" state it should accept more
requests, in "busy" state it will just queue them or maybe even ignore
them.

>> So "cmake --build" is out of scope for the daemon?
>
> I listed three ways cmake and an IDE could interface here:
>
>  http://thread.gmane.org/gmane.comp.lib.qt.creator/11794/focus=15411
>
> 'triggering the build' would be a fourth. I don't think it needs to be part
> of the initial discussion of the design.
>
> Let's try to keep scope small so that we can get on common ground.

So let's forget about all the interactive stuff for now. That is IMHO
step 2, after the basic protocol is validated by implementing bare
bones project information:-)

>> That is why I brought up progress information so early: They make things
>> complicated by there suddenly being several responses to a request and you
>> need a way to identify those. At that point simpler solutions tend to blow
>> up:-)
>
> Yes.
>
> BTW: I don't expect to get any part of the design of the protocol 'right' on
> the first iteration. I think we need to start everything that will need to
> be in the protocol, then iterate. Start high level ignoring details, and
> fill in the details as we iterate and can encode needs in unit tests.

I agree and do not expect anything different.

Basic protocol functionality from my point of view needs to include:
* Being able to detect the daemon or IDE becoming unresponsive
* Being able to find which responses are the result of which requests
* Being able to reliably find what kind of object I got as request or response

>From the point of view of an IDE: Being able to have progress
information is not a high level detail to be filled in later.

Best Regards,
Tobias
-- 

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 mode protocol

[Tobias Hunger]

Hi Stephen,

Am 15.01.2016 00:38 schrieb "Stephen Kelly" :
> > * Start daemon-mode without any additional parameters
> >
> > * Daemon responds with "
> >   {
> > "type": "handShake",
> > "version": "3.5.x",
> > "supportedProtocols": "3.5"
> >   }
>
> As you discovered, the cmake binary might not even support the daemon mode
> at all.

That is really straight forward to detect: It will send malformed JSON on
stdout if daemon-mode is unsupported:-) The error message you get is not
JSON and definitely on of type handShake.

> I think what you are really asking for is 'the capabilities of the cmake
> binary'. In that sense, you might also want to know what generators are
> available, whether daemon mode is available (and with which protocol
> versions) etc.
>
> The issue at
>
>  http://public.kitware.com/Bug/view.php?id=15462
>
> proposes to dump that information to stdout with a different -E command.

I do not really see the need for that.

Daemon-mode is easy to detect by the reply to the attempt to start it.

Everything else I expect to extract from within daemon mode.

> >
> > * Client Handshake:
> >   {
> > "type": "handshake",
> > "requestProtocolVersion": "3.5"
> >   }
> >
> > * Daemon:
> >   {
> > "type:"handshake",
> > "protocolVersion": "3.5"
> >   }
>
> Something like this is possible too. It's not far off what is already done
> in the branch.

I know, that is what this is based on after all. All I want is to be able
to start daemon-mode without having a builddir that is already associated
with a sourcedir.

> > At this point the normal operation should be possible.
> >
> > * Client:
> >   {
> >  "type": "setProjectInformation",
> >  "sourceDirectory": "/some/path",
> >  "cookie": "1"
> >   }
> >
> >   Being able to set the source directory is important so that a fresh
> > checkout can be configured. There is no build directory available at
> > that time...
>
> I understand the desire to inspect a cmake project without asking the user
> to specify a build dir,

You can safely read the CMakelists at this point, give syntax errors, maybe
even extract basic information like project name at this point.

> but cmake has to write build files somewhere in
> order to test the compiler etc.

If this works with a temporary build directory, then these files probably
do not need to litter the build directory in the first place:-)

> 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.

Hey, the idea is to improve on the current situation, not to perpetuate the
workarounds.

And how do I associate an empty directory as a builddir to a sourcedir?

How can I switch between builds when the daemon-mode is set up to work with
one builddir? Do I have to close it down and start a new daemon for the
next build?

That would be suboptimal, as all the built-in dependent state of the
project would need to get regenerated by the new daemon. Associating a
daemon with a sourcedir and being able to switch builddir would be nicer.

> Is that viable? I suppose you are suggesting that cmake do that instead of
> leaving it for clients to do?

It is doable. I just do not see why this should be necessary.

The daemon is not need to persist its state to disk all the time like
command-based cmake currently needs to.

> > * Daemon should do progress handling while reading the CMakeLists.txt
> > or whatever it does:
> >   { "type": "progress", "state": "busy", "task": "someId",
> > "taskDescription": "Reading CMakeLists.txt files", "cookie": "1" }
> >
> > * Daemon sends occasional:
> >   { "type": "progress", "task": "someId", progressTotal: 25,
> > progressCurrent: 12, "cookie": "1" }
>
> Yes. CMake can provide approximate values of how complete the configure
step
> is. See cmGlobalGenerator::AddMakefile. That could be exposed to the
daemon
> 'somehow', such as by defining some virtual callback interface.
>
> Richer information about some semantics like 'task' and 'busy state' could
> also be provided in a similar way I expect, assuming those could be
defined.

This is some basic functionality that we should get right soon, as this can
influence how long-running tasks need to be designed.

> > * Finally Daemon responds sends data as that is available now.
> >   {
> > "type": "projectInformation",
> > "sourceDirectory": "/some/path",
> > "buildDirectory": "",
> > "projectName": "SomeProject",
> > "cookie": "1"
> >   }
>
> At this point in your proposal, cmake has run the configure step in a
> temporary directory, right?

I am currently arguing with complete ignorance of how cmake works
internally:-) This is just what I think makes the most sense from an IDE
perspective.

> So it would be
>
>   "buildDirectory": "/tmp/foo/bar"
>
> right?

No.

The daemon should be associated with a sourcedir, 

[cmake-developers] cmake daemon mode protocol

[Tobias Hunger]

Hi Stephen,

I have successfully build and run your cmake server mode changes and
the python client script does work as advertised.

I do have a couple of remarks about it. This is more intended as a
starting point for discussion as a real proposal. Would something
along these lines be possible:

* Start daemon-mode without any additional parameters

* Daemon responds with "
  {
"type": "handShake",
"version": "3.5.x",
"supportedProtocols": "3.5"
  }

* Client Handshake:
  {
"type": "handshake",
"requestProtocolVersion": "3.5"
  }

* Daemon:
  {
"type:"handshake",
"protocolVersion": "3.5"
  }


At this point the normal operation should be possible.

* Client:
  {
 "type": "setProjectInformation",
 "sourceDirectory": "/some/path",
 "cookie": "1"
  }

  Being able to set the source directory is important so that a fresh
checkout can be configured. There is no build directory available at
that time...

* Daemon should do progress handling while reading the CMakeLists.txt
or whatever it does:
  { "type": "progress", "state": "busy", "task": "someId",
"taskDescription": "Reading CMakeLists.txt files", "cookie": "1" }

* Daemon sends occasional:
  { "type": "progress", "task": "someId", progressTotal: 25,
progressCurrent: 12, "cookie": "1" }

* Daemon sends (probably optional...):
  { "type": "progress", "task": "someId", "state": "done", "cookie": "1" }

* Finally Daemon responds sends data as that is available now.
  {
"type": "projectInformation",
"sourceDirectory": "/some/path",
"buildDirectory": "",
"projectName": "SomeProject",
"cookie": "1"
  }

* Client:
  {
"type": "setProjectInformation",
"buildDirectory": "/some/other/path",
"cookie": "2"
  }

* Daemon does progress indication as above...

* Daemon responds with project info:
  {
"type": "progressInformation",
"sourceDirectory": "/some/path",
"buildDirectory": "/some/other/path",
"projectName": "SomeProject",
"cookie": "2"
  }

We might also want a "ping"/"pong" to detect if the daemon is still
responding. That would require the daemon to be able to handle
multiple requests to be in flight... not sure that this is worth it.
But if we can not do that, then we need to provide constant progress
information, which is also not great:-)

Not sure about the need for cookies (text set by the client and
repeated by the server in all its replies to that request). I do think
having them makes sense, even when only one request can be active at
any time: They make it so much easier to sanity-check communication.

Consistently having a "type" in all messages going back and forth is
probably a good idea for the same reason as having cookies.

A final, remark unrelated to the protocol: Ideally the daemon should
delay writing into (and even creating!) the build directory for as
long as possible (or till instructed to actually persist the
configuration). We do have many users that use Qt Creator to browse
foreign code and those tend to get upset when we write stuff to disk.

Best Regards,
Tobias
-- 

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] [Qt-creator] CMake daemon for user tools

[Tobias Hunger]

Hello Stephen,

thanks again for your work and interest in IDE integration!

I read Bard's reply as meaning that your cleanup work is a great
benefit to cmake, but will probably not be available in the
foreseeable future (if at all).

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 current state -- as I see it -- is this: While I like cmake for
command line use, it is the worst build system with regards to IDE
integration that I have to support in Qt Creator.  Even autotools
support is less than half the code needed to support cmake -- and
believe me, I never expected to give autotools as a positive
example;-)

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, CMakeLists.txts, resources, ...)
* Files that belong to the build system (anything that needs watching
to re-generate the IDE-integration information at the right times)
* Targets that can be built
* Files that belong to each target
* Compiler flags
* Defines in effect
* Include paths used
* The compilers used to build those files

Ideally I would not need to write files to disk to get that
information. I do not know enough about cmake internals to suggest the
best approach to implement this, but something that can be extended
would be great, as this is really just the very basic information
needed and more information would be welcome at a later point.

Interactive features like syntax highlighting of CMakeFiles or adding
files to the build system in are of little interest to me at this
point: I see little reason to implement anything along those lines
while I can not reliably read the information needed for the code
model.

Best Regards,
Tobias

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 

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

[Tobias Hunger]

On Mon, Mar 30, 2015 at 7:04 PM, Anton Makeev
anton.mak...@jetbrains.com wrote:
 Another item of note is that CMake does not know the compile flags as a
 sequential container of individual flags currently, but it knows them as a
 string (that's also why it appears as a string in my generated json
 currently).

 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
 * quote include directories are not distinguishable
 * compiler definition do not include compiler-defined(built-in) definitions
 etc.

 That is, to have the complete list of include directories and compiler 
 definitions, the IDE will have to call the compiler anyways.
 And here is where it will need the actual compiler’s command line.

Oh, yes, we do need the path to the compiler to be run, too.

I think we can combine the include_directories, compile definitions
and flags ourselves though when that is needed for us to run the
compiler. I do not see the need to have the full command line that
would be run for each and every file, which is how I read full
compiler command line.

 Should we had the full list of include directories (split into groups like: 
 , quote, and frameworks) and the list of all compiler defines, we would not 
 need the compiler command-line at all.

We need the compiler binary anyway:-)

Best Regards,
Tobias
-- 

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] How to handle configurations (Was: Generating buildsystem metadata from CMake)

[Tobias Hunger]

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.

 The answer will be re-used in many other places. For example, if I have a
 CMakeLists like

  add_executable(main
file1.cpp
...
fileM.cpp
  )
  target_include_directories(main ...)
  target_compile_definitions(main ...)

 then we could either write the definitions and includes once (associated
 with the target), or we could repeat them all M times (once for each file).
 That could be lots and lots of repetition, repeated N times, once for each
 configuration.

... or define a group of files, put all the files into that group and
add the other relevant flags.

If there is a file that needs something different, then just add that
as a separate group.

In the normal case where all files have the same flags applied the
overhead should be close to the minimum. And it still allows for
having different settings for different groups of files without the
IDE needing to combine settings. E.g. if main.cpp defined TEST=1,
while the main-target defined TEST=2, which one will win?

Please do not require all IDEs to implement logic found in cmake.
There will always be corner cases where this will fail, leading to a
broken code model in the IDE.

 I personally prefer minimising the repetition, as I did in the unit test I
 pushed to my clone. I have the feeling you guys have not looked at the unit
 test I pushed to my clone. Please go ahead and do that if not. Also, when
 proposing json formats, please imagine how your proposal would represent the
 data in Tests/Metadata/CMakeLists.txt.

I am not sure I understand cmake well enough to do that correctly:-/
But I'll give it a try.

 I'd actually prefer having a configurations key with the list of the
 configurations an object applies to.

 That can be optional if the object is relevant to all configurations
 (default in single-configuration generators;-).

 This key would then need to be applicable to targets as well as the
 group of source files.

 So that would be something like this:

 Could you post what would be generated by your proposed structure for the
 unit test file in my branch?

 That would most likely avoid quite a bit of duplication in the file(s).

 How does the design goal of 'avoid duplication' weigh against the design
 goal of 'don't make me combine multiple properties together to get relevant
 information (eg target defines and additional source defines)', in general?

 We can either go for one extreme or the other, but I don't think it makes
 sense to go for something in between. That would be the worst of both
 worlds.

 So, for the proposals which are on the table, please either use the
 Metadata/CMakeLists.txt file in my clone, or post an alternative together
 with the json which you propose we should generate for it, and a prototype
 or pseudo-implementation of a parser for that json.

Attached you find something that is close to what I want. I moved the
sections in your version of that file around a bit in a text editor,
so this might not be valid json:-) This does not really cover the
conditions though, as those were not in your file either. Note how the
main.cpp is handled differently from your proposal.

i do not see configurations as much of a problem in such a setup: Just
add them as tags to each group of files (and each target). That way
the configurations can be handled just as the other differentiators
(language, type) in the file groups/targets. That should reduce the
duplication, still be pretty readable and should be reasonably simple
to parse.

Best Regards,
Tobias


cmake-metadata-Linux-GNU-4.9.json
Description: application/json
-- 

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] Generating buildsystem metadata from CMake

[Tobias Hunger]

On Sat, Mar 21, 2015 at 9:41 AM, Stephen Kelly steve...@gmail.com wrote:
 Anton Makeev wrote:

 The other thing that seems troubling to me is that since file, target,
 language compiler options are split into different parts of metadata, the
 IDE need to know exactly how to assemble them back into the compiler’s
 command line (e.g. what flags go first file’s or language’s), duplicating
 CMake's logic that may be different from version to version and from
 compiler to compiler. The exact command line is needed to get the actual
 and precise defines, include search paths etc. from the compiler.

 Yes. I previously proposed the lang_compile_command to contain information
 about how to built it:

  
 http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.html#optional-properties

 However, I think it might be better to generate something similar to what is
 currently generated in compile-commands.json into cmake-metadata.json. That
 is, we would generate (in some context)

  include_directories : [/foo, /opt]
  compile_definitions : [DEF=\Foo\, OTHER_DEF=1]
  compile_command: -c -DDEF=\Foo\ -DOTHER_DEF=1 -I/foo -I/opt

 So, compile_command contains approximately what you can currently get from
 compile-commands.json.

 The other properties contain things which are specifically known to be
 include directories or compile definitions, as javascript arrays. These
 properties are obviously redundant information, so I wonder if they should
 be generated at all? Is the compile command I wrote above easy to parse? Or
 is it sufficiently difficult to parse that this redundant information should
 be provided?


How about include_directories, compile_definitions and compile_flags?

So something along the lines of:

include_directories : [/foo, /opt]
compile_definitions : [DEF=\Foo\, OTHER_DEF=1]
compile_flags: [ -c ]

Parsing things is always error prone. Is that -D for definitions or /D?

The compiler flags are definitely needed though. They are used to e.g.
decide which dialect of a language are used.

This would keep parsing simple and will also provide all the
information we need.

linker_flags might also be interesting...

Best Regards,
Tobias
-- 

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] Generating buildsystem metadata from CMake

[Tobias Hunger]

Hi Anton,

you raised some good points, all of which I agree with:-)

On Thu, Mar 19, 2015 at 10:18 AM, Anton Makeev
anton.mak...@jetbrains.com wrote:
 * If it is useful to preprocess/compile/assemble individual files from
  IDEs, as made possible by the Makefiles and Ninja generators, we'll need
  to design that.
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429


 This is definitely useful, but I’m not sure what kind of information needed
 here,
 as I see it, since we already know the files in the project, we can tell
 make/ninja to simply compile it.

You asked me to use cmake --build, so ideally that would be cmake
--build . /full/file/path and ideally it would work with all
generators without magic in the IDE:-)

Since I assume that not all build systems will allow to build
individual files, you might want to add a flag
can_build_individual_files or similar to the metadata that a
generator can use to flag the IDE on whether the generated build
system can build individual files or not. Then the IDE can hide that
option if it is not applicable.

 * Some more information from project() may be relevant, but it's not clear
  yet. We will likely know more when we have decided the file format and
  generated some 'interesting' metadata files.


 Project name, list of the configurations are most needed ones.
 We also use CMAKE_lang_SOURCEFILE_EXTENSIONS to determine if a given file
 is potentially source file or not.

I would also love to see subprojects:-) CMake allows for them, doesn't it?

Will you still need CMAKE_lang_SOURCEFILE_EXTENSIONS when you can
get access to the list of sources as above where each group of files
is flagged with the language, etc.?

snip

 As a side note, it seems more natural to me to have one json file with one
 or several configurations listed, providing that there is also shared
 project info that should be in that files.
 something like that:

 project: ProjectName
 configurations: {
  {
name: Debug
targets: {...}
  },
  {
   name: Release
targets: {...}
  }
  ...
 }

I'd actually prefer having a configurations key with the list of the
configurations an object applies to.

That can be optional if the object is relevant to all configurations
(default in single-configuration generators;-).

This key would then need to be applicable to targets as well as the
group of source files.

So that would be something like this:

{
  project: TestProject,
  targets: [ {
name: Debug only,
configurations: [ Debug ],
type: EXECUTABLE,
sources: [ ... ]
  },
  {
name: Release only,
configurations: [ Release ],
type: EXECUTABLE,
sources: [ ... ]
  },
  {
name: Run Tests,
sources: sources: {
language: C++,
defines: FOO=1,

sources: [ {
  type: sources,
  name: Critical source files,
  configurations: [ Debug ],
  include_paths: /some/path,
  files: [ /full/path/a.cpp, /full/path/b.cpp ]
},
{
  type: headers,
  files: [ /full/path/a.h ]
},
{
  type: generated,
  files: [ /full/path/config.h ]
},
{
  type: sources,
  name: Tests,
  include_paths: /some/path,
  files: [ /full/path/a.cpp, /full/path/b.cpp, /full/path/test.cpp ]
} ]
  }
}

That would most likely avoid quite a bit of duplication in the file(s).

  This also means that conditions don't need to be added inside the metadata
  file for configurations in order to show files 'excluded' by being part of
  a non-active configuration.  The code implementing discovery of excluded
  files is in the generate-metadata branch in my clone.

Yeap, that would be a convenient property for me, too.

snip

 * Generating metadata only (without generating buildsystem files) is not
  currently in scope.  This was requested several times, but it is not
  clear why.


 It’s simply to be able to get this the information as quickly as possible.
 I’m not sure which part is most slow, but, say, InsightToolKit 4.5
 (http://www.itk.org/Wiki/ITK/Source), generates in couple of minutes. The
 regeneration, even when nothing was changes, a few dozens of seconds.

 Plus, we’d prefer being able to open the project without any questions to
 user, e.g. not asking, which generator he/she prefers. If we generate using
 ‘wrong’ default generator we’ll need to regenerate everything again when
 user decides to change it.

 Another benefit of skipping actual generation is possibly better error
 recoverability.
 That is, some generators may fail here and there if the project is
 incorrectly configured (e.g. source files are missing). Skipping the
 generation phase will (probably) help getting the project metadata even in
 that case.

 But anyway, it seems a little outside of the scope of the discussion.

Very good points that I fully agree with.

 * How much information does tooling need about installation?  Targets
  can use different include directories and compile definitions in their
  install 

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

[Tobias Hunger]

Hi Stephen,

On Thu, Mar 19, 2015 at 2:22 AM, Stephen Kelly steve...@gmail.com wrote:
 * In Target Properties/Conditional Properties and optional
 properties: Would it make sense to have a list of target_files, each
 with a filepath and a type? That would be more similar to the targets
 which also are a list with name/type.

 What semantics would the 'type' have? I don't really understand what you
 propose here.

See the examples with the sources below:

sources: [ {
language: C++,
type: sources,
defines: FOO=1,
include_paths: /usr/include,
files: [ /full/path/a.cpp, /full/path/b.cpp ]
},
{
language: C++,
type: headers,
files: [ /full/path/a.h ]
},
{
language: C++,
type: generated,
files: [ /full/path/config.h ]
}]

The type is used to distinguish between the different kinds of files.
Your proposal uses different keys for all the different kinds of
files, my is to use the same key for all sources and distinguish
between them by giving a type.

snip

 These configurations are only relevant to generators that can support
 e.g. having debug and release builds in the same build directory or
 did I misunderstand this?

 Yes, your understanding is correct.

 How are we supposed to handle a set of files for these configurations?

 Yes, that's how I see it working...

 How can we notice when one gets added and removed?

 I'm not experienced enough with those generators to know. I'm not even
 certain whether it is possible to add to the list of configurations for
 those generators, or if the list is hardcoded.

 Something to look into or get information from someone else on this list if
 they know.

 I think in the worst case, you'd watch the CMakeCache.txt and read the
 CMAKE_CONFIGURATION_TYPES from there. I know you want to care about only one
 file, but maybe two is not so bad :), and there is potentially other stuff
 in the cache which might be useful, and which might not lend itself to the
 json metadata file. We'll have to see.

So we are back to parsing random files in internal formats again:-)

Could you add have a configuration list key in the top level of each
file that lists all available configurations (including itself)? That
might be the lowest overhead solution that does not require parsing
extra files that I can think of right now.

I definitely will not hardcode cmake generator-A has configurations X
and Y while generator-A supports configurations X, Z and D into the
cmake plugin. I do prefer not to support configurations at all to
doing that.

snip

 * Make it more easy for an IDE to support actions such as 'remove file
   from the project', which requires removing it from the CMakeLists.txt
   at the appropriate place, and 'add new file/class to target', which
   involves adding code to the CMakeLists.txt file at the appropriate
   place.  Most likely the easiest way to do the latter is using the
   target_sources() command, and to support the former, the location of
   the declaration of the target, and all target_sources() calls would
   need to be recorded.  Even that is not enough because of transitive
   consumption of source files through the link interface, but that is
   likely irrelevant.

 That would be the icing on the cake, but getting a full description of
 the project is what I care for at this point.

 Can you expand on what 'a full description of the project' means to you? Do
 you mean something different than 'how each object is compiled'?

When you open a project in Creator we offer to import existing
builds (at least for qmake-based projects, none of the other build
systems supports this yet). That is very convenient when you blew away
the .user file we put into the sources directory with all the
information on how you built stuff where.

What we do there is to check the default project build location for
folders that contain a build of the current sources.

To do so we need to know which code was built in that directory and
which kit (think set of compiler, Qt, some other settings) were used
to in the built in that directory. We also need to figure out the
exact configuration (parameters passed to the configure step of the
build system) that was built there.

Since this is a feature our qmake users love I would also like to make
that possible with cmake. It would be great if I could get most
answers from the json file.

 * I don't generate 'dependencies' (actually the list of files which the
   buildsystem re-generation depends on) as Aleix did, because there is no
   well-defined usefulness for that list yet.

 How is the IDE supposed to know that it needs to re-run cmake then? If
 a file changes that may very well change the list of files that the
 IDE needs to display, so re-running cmake only at the next build is
 not going to work.

 Ok, I didn't realize that's the scenario we're talking about for that
 content. Are you saying that you would

   Set up a 

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

[Tobias Hunger]

On Sun, Mar 15, 2015 at 6:17 PM, Peter Kümmel syntheti...@gmx.net wrote:
 The idea was that qtcreator then also could parse and change the
 CMakeLists.txt file (like it is done with qbs files, I assume).

That would be a nice to have feature, yes, but I doubt that this will
ever be an option with cmake. And I personally do not want to pile
anything on top of cmake to enable this for a small subset of
still-to-be-written projects.

I would like to get to the point where you are able to build cmake
projects, configure them and have creator open the correct
CMakeLists.txt for you when you need to add/remove files to/from some
target. It will need work in Creator to get there, and I really do not
want that to end up relying on what I consider to be a implementation
detail of cmake -- like the format of (probably even undocumented)
files somewhere in the build directory that were meant for other
consumers.

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.

Best Regards,
Tobias
-- 

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] Extracting target metadata, IDE integration

[Tobias Hunger]

Hi Peter,

CMake does know all the headers or it could not decide which files
need rebuilding.

How would making cmake parse a file in the syntax of another build
system help creator understand existing cmake projects?

This is not about extending cmake language: It makes cmake generate
another description of the project in a format that IDEs can use, in
addition to the description stored in the Makefiles (or whichever
other build tool).

Best Regards,
Tobias
-- 

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