Re: [cmake-developers] [CDT] Improving CDT4 generator

2019-03-20 Thread Alexander Neundorf
On 2019 M03 20, Wed 13:53:49 CET Brad King via cmake-developers wrote:
> On 3/19/19 4:57 PM, David wrote:
> > since Eclipse 9.2 (or 9.1 do not remember), the CMake CDT4 Generator
> > does not work as expected for C++ Project.
> > 
> > What is the best way to propose an update ?
> 
> Please see contribution instructions here:
> 
>   https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst
> 
> However, it would be better to work with Eclipse upstream to use
> CMake's new file-api:
> 
>   https://cmake.org/cmake/help/v3.14/manual/cmake-file-api.7.html
> 
> That is now the intended way for third-party IDEs to display CMake projects.

so this is now preferred over the server-mode ?

Alex



-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] Fwd: [CMake] link only with targets feature

2019-02-12 Thread Alexander Neundorf
On 2019 M02 12, Tue 08:34:57 CET Timothy Wrona wrote:
> I saw this email come through the cmake users mailing list but feel it is
> more fitting for it to go to cmake-developers so I'm forwarding it here.
> 
> It is a pretty long rant, but I think his idea to add a keyword to the
> "target_link_libraries()" command that would only look for cmake targets is
> a pretty great idea. I dont think it would break backwards compatibility
> either.
> 
> For example:
> 
> target_link_libraries(mytarget
>   LINK_TARGETS
> target1
> target1
> )
> 
> This would only search for CMake targets to link to and would not search
> for libraries with the same name. It would make adding alias namespace to
> targets not necessary anymore and would potentially make a lot of code look
> cleaner.

(I already replied on the cmake-list before I saw this here).
I would prefer if this could be combined with the include-directories via 
linking feature.
E.g. a command target_link_targets() which accepts only targets, and which has 
the include-directories features, and a policy to disable the include-
directories via target_link_libraries().

Alex

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] CMake Cache Library

2018-11-13 Thread Alexander Neundorf
On 2018 M11 12, Mon 17:53:38 CET Taylor Holberton wrote:
> Hello everyone!
> 
> Today I released a short and sweet C++ library for accessing and modifying
> CMake Cache files.
> 
> Feel free to use it, critique it, or ignore it entirely.
> 
> You can find it on GitHub, at https://github.com/tay10r/cmake-cache
> 
> Thanks!

did you really choose GPLv3 as license for this ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] How to handle dependencies of protobuf files ?

2018-05-29 Thread Alexander Neundorf
Hi,

On 2018 M05 29, Tue 09:52:16 CEST Brad King wrote:
> On 05/15/2018 03:45 PM, Alexander Neundorf wrote:
> > I think to do it properly, there would have to be a dependency scanning
> > for
> > proto files like there is for C/C++ headers.
> 
> In order to handle implicit dependencies like that implied by
> 
> import "MyBase.proto";
> 
> then they would somehow need to be extracted from source content.
> Ideally protoc should be able to write a depfile as a side effect.
 
Parsing them using cmake would more or less work, also the include dirs are 
known, so technically this would probably work. But the parsing would happen 
at cmake-time, not at compile-time, but editing a proto-file does not trigger a 
cmake run...
Would that have to be implemented similar to the C dependency scanning ?

> Otherwise all dependencies should be listed explicitly somewhere.

so the cheap solution would be to add an argument to PROTOBUF_GENERATE_CPP() 
to list proto-files these proto-files depend on which is forwarded to (every) 
add_custom_command() call inside PROTOBUF_GENERATE_CPP().

Not very elegant, but at least it would make it work correctly.

This would require that if in a set of proto-files there are different 
dependencies, for each of those with different dependencies a separate 
PROTOBUF_GENERATE_CPP() would be needed.
A bit ugly, but better than now.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] How to handle dependencies of protobuf files ?

2018-05-25 Thread Alexander Neundorf
Any comments ?

Alex

On 2018 M05 15, Tue 21:45:06 CEST Alexander Neundorf wrote:
> Hi,
> 
> I stumbled upon a problem with protobuf files, I attached a testcase.
> There is a MyBase.proto, which is "imported" by Complex.proto.
> If MyBase.proto is modified, protoc is run again in MyBase.proto, but not on
> Complex.proto, although it should.
> You can have a look at the attached example.
> 
> The message MyData (in Complex.proto) has a member MyBase b1.
> If I rename the message MyBase (in MyBase.proto) e.g. to MyBaseXYZ, then the
> build fails, because Complex.pb.h was not regenerated, so it still refered
> to the now not existing class MyBase.
> 
> Is there already a solution to handle this ?
> 
> I think to do it properly, there would have to be a dependency scanning for
> proto files like there is for C/C++ headers.
> Parsing at the proto-files at cmake time wouldn't be good enough (since
> editing a proto file doesn't trigger a cmake run).
> 
> Comments ?
> 
> Alex


-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers


[cmake-developers] How to handle dependencies of protobuf files ?

2018-05-15 Thread Alexander Neundorf
Hi,

I stumbled upon a problem with protobuf files, I attached a testcase.
There is a MyBase.proto, which is "imported" by Complex.proto.
If MyBase.proto is modified, protoc is run again in MyBase.proto, but not on 
Complex.proto, although it should.
You can have a look at the attached example.

The message MyData (in Complex.proto) has a member MyBase b1.
If I rename the message MyBase (in MyBase.proto) e.g. to MyBaseXYZ, then the 
build fails, because Complex.pb.h was not regenerated, so it still refered to 
the now not existing class MyBase.

Is there already a solution to handle this ?

I think to do it properly, there would have to be a dependency scanning for 
proto files like there is for C/C++ headers.
Parsing at the proto-files at cmake time wouldn't be good enough (since editing 
a proto file doesn't trigger a cmake run).

Comments ?

Alex


protodeps.tar.gz
Description: application/compressed-tar
-- 

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] new generator question - xml file output for embedded IDE platforms.

2018-05-02 Thread Alexander Neundorf
On 2018 M05 2, Wed 09:17:53 CEST du...@duaneellis.com wrote:
> >> configure_file is not the right command
> 
> Yea, it's the nearest existing item, and it only does the most
> simplistic replacement that's why I use that as a basis for my example.
> It is in effect, like the final last 'sed' step done by gnu
> autoconfigure tools. Nothing more.
> 
> >> If an IDE is actually not supported by CMake a generator it will have to
> >> be implemented for that in the source code of CMake.
> yea, i'm trying to avoid that - but I can write that if required :-(

I think you'll have to do this.

> 
> It's more then the IDE, it is also the CHIP effectively the SYSTEM
> 
> What I need is the variable data that Cmake has already and I need to be
> able to tell CMake that it *cannot* run the compiler instead, all of the
> information about the compiler will be provided via some Cmake script,
> for example names like this, either on the command line or specified in
> a Cmake file that holds alot of variables.
> 
>Cmake-Embedded-${CompilerName}.txt
>Cmake-Embedded-${ChipName}.txt
> 
> Possibly:
> 
>Cmake-Embedded-${RtosName}.txt
> 
> or
> 
>Cmake-Embedded-BareMetal.txt

this exists basically.
The files cmake loads are named --.cmake.
In CMake there are e.g. Generic-SDCC-C.cmake.
This would be "BareMetal" using sdcc.
You can write your own files for your own platforms.
OS and other settings can be set up in your toolchain file.

Are you familiar with cmake cross-compiling support in CMake ?
If not, please get into this, it handles many of the issues you have.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] Adding a non-make based generator

2018-04-17 Thread Alexander Neundorf
Hi,

On 2018 M02 14, Wed 22:16:54 CEST Alexander Neundorf wrote:
> On 2018 M02 14, Wed 18:46:52 CET Saeed, Khurram wrote:
> > Thanks Alex.
> > Yes it does support generating the project in the build dir. It also works
> > while generating in a subdir of the source dir. Eclipse version control
> > plugin also works (I am using git).
> 
> Interesting.
> How did you get that working ?
> 
> Let's say the directories look like this:
> 
> src/CMakeLists.txt
> build/CMakeCache.txt
> build/.project
> build/.cproject
> 
> I guess this is what you generate, right ?
> How do you get the source tree into this project ?
> The Eclipse-generator in cmake uses a "linked resource" to the source dir,
> but the version control plugin is not activated for those files.
> According to the Subversion-Plugin developers this is because the source
> files are then outside the "project directory", i.e. no below the directory
> where the .project file is located.
> 
> So I'm really interested how you got that working.
> Can you send the .project and .cproject files for a simple hello-world
> project, built out-of-source ?

any news here ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] Adding a non-make based generator

2018-02-14 Thread Alexander Neundorf
On 2018 M02 14, Wed 18:46:52 CET Saeed, Khurram wrote:
> Thanks Alex.
> Yes it does support generating the project in the build dir. It also works
> while generating in a subdir of the source dir. Eclipse version control
> plugin also works (I am using git).

Interesting.
How did you get that working ?

Let's say the directories look like this:

src/CMakeLists.txt
build/CMakeCache.txt
build/.project
build/.cproject

I guess this is what you generate, right ?
How do you get the source tree into this project ?
The Eclipse-generator in cmake uses a "linked resource" to the source dir, but 
the version control plugin is not activated for those files.
According to the Subversion-Plugin developers this is because the source files 
are then outside the "project directory", i.e. no below the directory where 
the .project file is located.

So I'm really interested how you got that working.
Can you send the .project and .cproject files for a simple hello-world project, 
built out-of-source ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] Adding a non-make based generator

2018-02-09 Thread Alexander Neundorf
Hi,

On 2018 M02 9, Fri 13:16:19 CET Saeed, Khurram wrote:
> Hi Alex,
> 
> I have not made it available anywhere so far. Although my target while
> writing this generator was only to make it work for ReadyStart projects.
> However, I think with some effort down the road it might be possible to use
> it for normal Eclipse CDT projects as well.
> 
> We want to make it available to general public but we have been wondering
> whether or not it would be "acceptable" to have a generator that generates
> managed Eclipse CDT projects?

well, Brad is the maintainer.
I think in general a "real" Eclipse CDT project generator would be preferred 
over the existing one which generates a makefile-based project for Eclipse.

I could try to support you a bit.

Does it support generating the project in the build dir, i.e. outside the 
source dir (or in a subdir of the source dir), and does then the Eclipse 
version control plugin (svn/git) work ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] Adding a non-make based generator

2018-02-07 Thread Alexander Neundorf
Hi Kurram,

On 2018 M02 7, Wed 12:09:54 CET Saeed, Khurram wrote:
> Hi Neundorf,
> This generator can only be used for generating Nucleus ReadyStart IDE
> projects. It generates Eclipse CDT project files that use ReadyStart
> specific plugins and configurations.

I have the impression Brad was not overly excited.
On the other I have the impression that the Eclipse CDT team is also not 
overly excited of the cmake server mode (at least 2 years ago when I was on 
the mailing list).

Would it be hard to extend your generator so that it can also be used for 
"normal" Eclipse CDT projects ? Is it already available somewhere, e.g. github 
?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] Adding a non-make based generator

2018-02-02 Thread Alexander Neundorf
Hi Saeed,

On 2018 M02 2, Fri 15:05:19 CET Saeed, Khurram wrote:
> Hi,
> Nucleus
> ReadyStart is
> an eclipse based IDE by Mentor Embedded(tm).
> It is used for creating and building C/C++ based Nucleus
> RTOS projects for
> embedded devices. We have added a new generator in CMake to give the option
> of generating Nucleus ReadyStart based projects to our customers. This is
> not a 'make-based' generator as Nucleus ReadyStart projects are built using
> Eclipse CDT managed build system. In this generator we are generating
> .project and .cproject files for Nucleus ReadyStart application.
> 
> Do you think we can contribute this generator to community?

does that mean it also works for "normal" Eclipse CDT, or only for ReadyStart 
?
If it works for Eclipse in general, I would happily remove the current Eclipse 
CDT generator (which I wrote).
Do all tests pass using your generator ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] kwsysProcess threadsafety

2018-01-08 Thread Alexander Neundorf
On 2018 M01 8, Mon 10:32:22 CET Jean-Michaël Celerier wrote:
> > 3) Abandon the idea to parallelize AUTOMOC/UIC
> 
> please no ! moc is a huge bottleneck in my builds (to the point that using
> verdigris  instead ends up having
> faster build time overall).

you could also just not use automoc and use the "manual" moc-wrapper macros. 
This should make the build-time overhead go away.
Instead the developer has to add the header file to be moc'ed to the 
CMakeLists.txt (personally I consider this acceptable).

Alex

-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers


Re: [cmake-developers] Antwort: Re: Non supported toolchain

2017-11-23 Thread Alexander Neundorf
On 2017 M11 23, Thu 07:22:19 CET oliver.za...@egoproducts.com wrote:
> Hi Alex,
> 
> thanks for your answer.
> 1. is there some guide or at least some example?
> 2. Does this module needs to be in the offical build to be distributed or
> is there a possibility to distribute the modules locally?

you could have a look e.g. at Modules/Compiler/TI*.cmake, or the IAR files.

You can try whether you can have your custom files in some directory and adjust 
CMAKE_MODULE_PATH accordingly. I'm not sure, but it might work.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] Non supported toolchain

2017-11-22 Thread Alexander Neundorf
On 2017 M11 22, Wed 10:37:00 CET oliver.za...@egoproducts.com wrote:
> Hi,
> 
> i know this is the dev mailing list, but i tried to solve my problem in
> the normal one (see here
> https://www.mail-archive.com/cmake@cmake.org/msg57862.html) with no
> success.
> 
> In Short: i have a toolchain for an microcontroller (renesas rx serjes)
> running on windows. I want to build my project with cmake and therefor
> wrote a toolchain file.
> The problem now is, that the compiler needs instead of "-I" for includes
> "-include=" and for defines "-define=". I found out that there seems to be
> internal variables CMAKE_INCLUDE_FLAG_C and CMAKE_DEFINE_FLAC_C but they
> don't seem to accesible from the toolchain file.
> 
> Is there any chance beside writing a new module for a compiler to get this
> toolchain running?

no, you probably need to write a module file for the compiler. This is actually 
not that complicated.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] Native Compilers

2017-09-26 Thread Alexander Neundorf
On 2017 M09 26, Tue 16:21:21 CEST Kevin Funk wrote:
> On Monday, 25 September 2017 20:39:01 CEST Ivam Pretti wrote:
> > When you use cmake-gui, below the button configure  there is an option to
> > choose the compiler. This compilers are alredy intalled with cmake or it
> > needs to install separetely?
> > 
> > Another question, when you specify a for example kdevelop files is it
> > necessary to run at kdevelop to get the executables files?
> 
> Heya,
> 
> Not sure if you took KDevelop just as an example, but let me clarify that
> the generator for the KDevelop project files is unmaintained (to my
> knowledge). [1]

yes, it's actually for KDevelop 3.
Maybe it should be removed ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] Feature suggestion: auto-create missing files

2017-04-11 Thread Alexander Neundorf
On 2017 M04 11, Tue 11:52:52 CEST Brad King wrote:
> On 04/11/2017 11:41 AM, Petr Kmoch wrote:
> > Currently, adding a new source file to a CMake-controlled project
> > means doing two things: creating the file on disk, and adding it
> > to the relevant CMakeList add_library() or add_executable() call.
> 
> I view this as a matching pair with an implicit sanity check.
> 
> > switch from current behaviour of "error out if source file is not found"
> > to "create empty source file if it's not found."
> 
> So a typo in the `CMakeLists.txt` file leads to silent creation of a
> source file instead of an error message?
> 
> That said, I can see how the proposed feature might be useful when
> iteratively developing in an IDE.  Add the file to `CMakeLists.txt`,
> reconfigure, and open the new (now existing) file to edit in the IDE.
> 
> > Is this something that would be acceptable into CMake? Any comments?
> 
> I'd like to hear more opinions from others before considering it
> upstream.  It feels like a pretty personal workflow right now, and
> can be implemented in CMake code already (perhaps with the `SOURCES`
> target property to avoid separate lists).

personally I'm not convinced.
Technically it would violate the "the source dir is read-only" rule.
A typo would generate files. With multiple build dirs the behaviour will be 
slightly different in the two dirs.
...not very strong arguments, but OTOH touching the file manually is also not 
too complicated.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] Eclipse CDT Managed build

2017-01-25 Thread Alexander Neundorf
On 2017 M01 25, Wed 11:38:06 CET Brad King wrote:
> On 01/25/2017 11:27 AM, Ben Boeckel wrote:
> > not be trivial to get CMake to generate relocatable builds.
> 
> This is also an explicit non-goal of CMake.
> 
> >> after CMake generation the project can be configured through the IDE UI.
> 
> That is likely not compatible with CMake's notion of maintaining
> the build system.
> 
> This is why previous similar discussions resulted in the cmake server
> mode and in identifying the value of a declarative spec format that
> can be managed outside of CMake's language processor.

IOW, now that cmake has server-mode, the recommended approach is to implement 
a plugin for cmake-server mode in Eclipse.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] [Discussion] Down with discrimination CPack!

2017-01-18 Thread Alexander Neundorf
On 2017 M01 18, Wed 22:20:14 CET Konstantin Podsvirov wrote:
> What about add to CMake language new packaging problematic scopes:
> 
> - COMPONENT;
> - COMPONENT_GROUP;
> - PACKAGE;
> - INSTALLER;
> - REPOSITORY?

that's a quite terse proposal...

Alex


-- 

Powered by www.kitware.com

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

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

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

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

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


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

2016-06-09 Thread Alexander Neundorf
On Thursday 09 June 2016 12:59:40 Tobias Hunger wrote:
> Hi Milian,
...
> > >   "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).

Getting the source directory of a target should be reliable and a useful 
information I guess ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

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

looks like that's an FP7-project, so I wouldn't be too sure about its future 
once the project funding ends...

Alex


-- 

Powered by www.kitware.com

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

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

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

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

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


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

2016-02-19 Thread Alexander Neundorf
On Friday, February 19, 2016 11:36:35 Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote:
> >> On 02/15/2016 07:24 PM, Tobias Hunger wrote:
> >> > Hi Dominik,
> >> > 
> >> > Am 15.02.2016 19:01 schrieb "Dominik Haumann"
> >> > <dhaum...@kde.org
> >> > 
> >> > <mailto:dhaum...@kde.org>>:
> >> > > 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).
> >> 
> >> I'd be up for a sprint in Berlin too, but given the muted response so
> >> far here, it's not clear who would want to join and what we could
> >> achieve.
> > 
> > just out of curiosity, did you get any feedback from anybody from
> > Eclipse/CDT ?
> 
> Nope. No response from there at all despite reaching out to them.

now that's a pity :-(

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2016-02-18 Thread Alexander Neundorf
On Wednesday, February 17, 2016 22:59:36 Stephen Kelly wrote:
> On 02/15/2016 07:24 PM, Tobias Hunger wrote:
> > Hi Dominik,
> > 
> > Am 15.02.2016 19:01 schrieb "Dominik Haumann"  > 
> > >:
> > > 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).
> 
> I'd be up for a sprint in Berlin too, but given the muted response so
> far here, it's not clear who would want to join and what we could achieve.

just out of curiosity, did you get any feedback from anybody from Eclipse/CDT 
? Or CodeBlocks maybe ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] [PATCH]: CodeBlocks: improve support for different compilers

2016-02-17 Thread Alexander Neundorf
On Tuesday, February 16, 2016 10:49:24 Brad King wrote:
> On 02/12/2016 03:24 AM, melven.roehrig-zoell...@dlr.de wrote:
> > Just a small patch for the CodeBlocks generator
> 
> Thanks!  Applied:
> 
>  CodeBlocks: improve support for different compilers
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=184da3f4

Thanks :-)
Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

2016-01-14 Thread Alexander Neundorf
On Thursday, January 14, 2016 21:31:51 Kevin Funk wrote:
> On Wednesday, January 13, 2016 10:16:44 PM Alexander Neundorf wrote:
> > On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote:
> > > Running version 3.2.2 on Ubuntu 15. I run the following command:
> > > 
> > > $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9
> > > -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config
> > > -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake"
> > 
> > are you sure you actually want to use the KDevelop3 generator ?
> > This is for the KDE3 version, and you are probably using the KDE4 version
> > of KDevelop ? For that you don't need these generated project files.
> > 
> > Actually I was thinking about removing this generator, because KDevelop3
> > is
> > really really old, not sure whether it is still available in current Linux
> > distributions.
> > 
> > Alex
> 
> +1 from my side, KDevelop 3 is super ancient (last release around 2008
> according to the interwebs). Get rid off the generator.

Brad, what's  your opinion on this ?
Removing this is something I could do :-)

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] Assertion hit in CMake for KDevelop on Ubuntu

2016-01-13 Thread Alexander Neundorf
On Wednesday, January 13, 2016 10:16:23 Robert Dailey wrote:
> Running version 3.2.2 on Ubuntu 15. I run the following command:
> 
> $ cmake .. -G"KDevelop3" -DCMAKE_C_COMPILER=gcc-4.9
> -DCMAKE_CXX_COMPILER=g++-4.9 -DCMAKE_BUILD_TYPE=$config
> -DCMAKE_TOOLCHAIN_FILE="../toolchains/linux_i686.toolchain.cmake"

are you sure you actually want to use the KDevelop3 generator ?
This is for the KDE3 version, and you are probably using the KDE4 version of 
KDevelop ? For that you don't need these generated project files.

Actually I was thinking about removing this generator, because KDevelop3 is 
really really old, not sure whether it is still available in current Linux 
distributions.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] CMake alternative language

2016-01-13 Thread Alexander Neundorf
On Wednesday, January 13, 2016 10:59:39 yann suisini wrote:
> Hi,
> 
> I'm a new user of CMake, but I just want to express my newcomer point of
> view.
> Honestly , I can feel the power of CMAKE, but it's a real pain to learn ...
> I'm using CMAKE for an embedded platform with a non GNU compiler , ant at
> the end the CMAKE description is longer than the one I built directly in
> Ninja.
> I had to write a python script to parse my eclipse project xml to create a
> list of sources files usable by CMAKE.
> The first thing I thought was: why this is not a part of cmake ? And the
> second thing was : why not using the scripting power of an existing
> language like Python(or other one) and add CMAKE as a framework / library ?

My personal opinion: if the full power of python would be available, the build 
scripts would quickly turn into real programs, because programmers would be 
tempted to do so if all of python would be available. Then developers would 
have to understand two programs: the program itself, and the "build program".

I'm not saying that the cmake language is beautiful, but it helps to keep 
cmake scripts somewhat simple, and not evolve into a second program 
additionally to the actual program which is being built.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2016-01-12 Thread Alexander Neundorf
On Tuesday, January 12, 2016 10:05:08 Brad King wrote:
> On 01/12/2016 05:15 AM, Tobias Hunger wrote:
> > I read Brad'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).
> 
> Most of Stephen's work completed so far is already in CMake 3.4, and
> a bit more is in 'master' and will be in 3.5.  It has no public-facing
> changes though so yes more work will be needed to get a solution IDEs
> can actually use.
> 
> > Alexander goes back to the generator approach we discussed a year ago
> > and explicitly says he won't work on that, so nothing will happen
> > there.
> 
> The generate-json-description approach remains a valid alternative.
> Aleix's work on it got pretty far before Stephen proposed the daemon
> alternative.  See more below.  IIRC Alexander Neundorf raised concerns
> only about how to activate the generation of the json description, and
> has now proposed an approach to resolve those concerns.

Yes, exactly.
But I really don't have the time to bring my branch up to merge quality: 
tests, documentation, compatibility (?, some generator names will fall away), 
corner cases. But these things are actually not complicated code, It's just 
work.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2016-01-12 Thread Alexander Neundorf
On Tuesday, January 12, 2016 23:20:14 Milian Wolff wrote:
> On Montag, 11. Januar 2016 23:22:23 CET Alexander Neundorf wrote:
...
> > Stephens big approach will need some time until it is ready, while such a
> > (relatively) simple thing can probably be done within one release cycle
> > (but I don't have the time to do it).
> > 
> > I don't know what the others here think about adding your json-approach or
> > not.
> 
> I don't think I'll have the required time to help here either, but I agree
> with your reasoning: Your patch is the potentially quickest to get something
> done. But it only fixes the usability issue of generators, it does not come
> with a useable generator which we'll still need to write.

I thought Aleix's patch was already quite good ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

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

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

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

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

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


[cmake-developers] (Experimental) Refactored extra-generators

2016-01-05 Thread Alexander Neundorf
Hi,

I spent a few hours on the extra-generators, and you can find the result here 
on github:
https://github.com/neundorf/CMake/tree/RefactorExtraGeneratorsExperimental 

In this branch, the extra-generators are not tied anymore hardcoded to the 
generators (so the generator list is short again), but each extra-generator 
can be enabled and disabled via a cmake option 
CMAKE_ENABLE_EXTRA_GENERATOR_.
I.e. for every build directory zero, one or multiple extra-generators can be 
enabled and disabled (in an existing build tree).

This would e.g. also be suitable for a generic JSON-generator.

The code on github is not ready to be merged, and unfortunately I don't have 
the time to bring it into mergeable state, including tests, documentation, 
etc.

But if somebody is interested, you can have a look and give it a try.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] Profile Cmake scripts

2015-12-27 Thread Alexander Neundorf
On Sunday, December 27, 2015 18:40:27 Dimitar Yordanov wrote:
> Hi all,
> 
> I was searching for a way to profile CMake scripts in order to find
> bottlenecks and possibilities to improve performance. I found out that
> someone already invested time on that [1] providing a minimal 
solution. The
> idea behind it is to use the cmake "--trace" option and to output a time
> stamp and a stack depth with each executed command. The trace log 
is
> afterwards used by a Python script, which transforms it into a more
> readable format.

I actually simply used valgrind/callgrind and got useful results from that.
Usually you see mostly string handling related functions.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] CMakeParseArguments: Test suite and native implementation

2015-12-17 Thread Alexander Neundorf
On Thursday, December 17, 2015 11:12:22 Brad King wrote:
> On 12/14/2015 04:52 PM, Matthias Männich wrote:
> > This adds a test suite for the CMakeParseArguments module. In 
addition
> > the second change implements cmake_parse_arguments(...) as 
native
> > command.
> 
> Thanks!  Applied with minor tweaks:


Cool :-)
Faster and one module less to load and care about :-)

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] set(CACHE) and the local scope

2015-12-11 Thread Alexander Neundorf
On Friday, December 11, 2015 14:44:39 Ben Boeckel wrote:
...
> Option 3:
> 
> set(CACHE) (and any other cache-touching behavior) does 
*nothing*
> with the cache if a local variable by that name is defined

just to clarify: and also does nothing to the local variable ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] set(CACHE) and the local scope

2015-12-10 Thread Alexander Neundorf
On Wednesday, December 09, 2015 17:35:28 Ben Boeckel wrote:
> Hi,
> 
> So some behavior I was unaware of until today came up:
> 
> set(var ON)
> option(var "description" OFF)
> message("var: ${var}")

Assuming I wouldn't know about the subtle characteristics of normal vs. 
cache variables, I think I would expect that var has the value of the option 
afterwards.

I.e. on the first run it would be OFF (since that's the default value of the 
option), and all later runs it would have the value which is in the cache.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] set(CACHE) and the local scope

2015-12-10 Thread Alexander Neundorf
On Thursday, December 10, 2015 15:26:54 Brad King wrote:
> On 12/10/2015 03:20 PM, Alexander Neundorf wrote:
> >> set(var ON)
> >> option(var "description" OFF)
> >> message("var: ${var}")
> > 
> > I.e. on the first run it would be OFF (since that's the default value
> > of the option), and all later runs it would have the value which is in 
the
> > cache.
> This is calling for the opposite change than Ben's proposal.  Ben
> suggests never unsetting the local value to expose the cached value.
> Alex is suggesting always doing so, even if the cache option is
> not created by the command.
> 
> Alternatively the option() or set(CACHE) commands could also set
> a local variable to the same value as the cache entry.
> 
> This is pretty fundamental behavior so if we are going to mess with
> it through a policy we better get it right.

Yes. :-)

My motivation: if the option() would just set/get the cache variable, and 
leave the local variable untouched, it would be a NOOP in the example 
above, and this is not obvious from seeing that code.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

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

2015-10-12 Thread Alexander Neundorf
Hi,

On Saturday, July 25, 2015 20:33:46 Stephen Kelly wrote:
> Aleix Pol wrote:
> > On Sat, Apr 18, 2015 at 11:56 AM, Stephen Kelly
> > 
> >  wrote:
> >> Stephen Kelly wrote:
> >>> The aim is to generate a structured file containing metadata 
relating
> >>> the buildsystem.
> >> 
> >> I've been quiet on this thread for a while, so I think it is time for an
> >> update.
> >> 
> >> I became more ambitious in mid March and started prototyping a
> >> more-complete design for CMake IDE integration.
> > 
> > Hi Stephen,
> > Is there any news on the subject?
> 
> I have been working on cleaning up cmake
> 
>  $ git log --oneline --author=steveire --since="April 1" | wc -l
>  472
> 
> I've made lots of progress toward separating the configure and 
generation
> steps (required prerequisite for server features), but no working 
prototype
> ready to show yet I'm afraid.

Maybe this is of interest: the Eclipse CDT developers are currently 
working on improved support for cmake:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=350206
http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg29621.html

But if I understand them correctly, this is not about improving support for 
projects which use cmake without eclipse, but to use cmake as the tool 
to generate the makefiles in Eclipse projects. But maybe I got that 
wrong.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [ANNOUNCE] DaD's House! (Beta)

2015-09-10 Thread Alexander Neundorf
On Thursday, September 10, 2015 16:02:23 Konstantin Podsvirov wrote:
> The first 100 views!
> The interest is there (though not great), but where are the questions and
> suggestions?

the web page is quite short on details...
It's not an IDE, is it a set of scripts ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] A policy for Policies

2015-06-22 Thread Alexander Neundorf
On Saturday, June 20, 2015 11:29:46 Stephen Kelly wrote:
 Brad King wrote:
  snip
 
 I recommend the following guidelines:
 
 1) Policies need to result in errors in a short timeframe. They are not
 something to ignore for years, because allowing that makes them feature
 toggles. Alex won't be happy with this one obviously, but that's what I
 recommend.

Just replace Alex with Users who don't want to spend time babysitting their 
buildsystem, .
 
 2) Policies need to result in unconditional warnings in a short timeframe.
 Even -Wno-dev should have no effect on the warning when the warning is
 unconditional. If third parties are using -Wno-dev to silence output they
 need to know that will no longer work. It only works while there is an OLD
 state for the policy.
 
 I don't think more conditions with deprecation states is a good idea. Policy
 lifecycle should be simple to understand. It should be a loud notification
 to people who see it that they have an action item on their hands.
 
 Here's my recommendation for a way forward:
 
 CMake 3.4:
 
 * Policies = CMP0011
 -- emit unconditional warnings for each policy (no OLD anymore - 6 years
 old)
 
 * Policies CMP0051 - CMP0054
 -- emit unconditional warnings for each policy (no OLD anymore - 3 releases
 old)
 
 * Policies CMP0026, CMP0024
 -- emit unconditional warning (CMP0026 warning will be in place for longer
 as many are affected, so start unconditional warning now). These are high
 priority because they make a better CMake implementation possible.
 
 CMake 3.5:
 
 * Policies CMP0001, CMP0003, CMP0004, CMP0006 - CMP0010
 -- emit unconditional errors for each policy (the ancient ones except 'the
 KDE4 policies')

Just so it doesn't sound only stupid: when I was still maintaining the KDE4 
buildsystem, I tried to avoid forcing users to have to update CMake (I always 
hate it if I try to do something on KDE, but instead of being able to start to 
do something, first I have to spend a day or two updating various stuff).
Ok, I wanted to avoid that for the cmake part.

So, let's say some version of KDE was released requiring CMake 2.4.5 (yeah, 
that old).
As long as there was no strong reason to require a newer version of CMake, I 
kept it at 2.4.5. Which implied, that the source should still be compilable 
with 2.4.5. Which, (at least to be on the safe side), also means, if there is 
a policy which results in a warning e.g. in 2.6.0, developers should not fix 
that warning with 2.6.0, since this might mean it does not work anymore with 
2.4.5.

Once a newer version of cmake is required, those policy settings may be 
changed. But even doing this means that developers may have to relearn some of 
their cmake skills, which is a cost, and shouldn't be forced without good 
reason.

Also, given the KDE4 source compatibility guarantees, kdebase 4.12 should 
still compile with kdelibs 4.3, and changing the cmake environments kde4libs 
is setting up influences this (and I had the impression that the uptake of 
more advanced cmake features in the wider KDE community was quite slow, e.g. 
learning about the subtleties of cmake policies).

So to me this still sounds reasonable.
 
...
 Of course all of this needs to be malleable. Let's see what the response is
 to the warning behavior in 3.4 if you apply it.

If there is a fixed date when the policy will result in an error, I'd consider 
it useful to have that date printed as part of the warning message.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] A policy for Policies

2015-06-10 Thread Alexander Neundorf
On Monday, June 08, 2015 09:57:14 Brad King wrote:
...
 This may be okay for CMP0011, but CMP0024 and CMP0026 were much
 more recent (3.0).  I think 5 years is a more reasonable cut-off
 than 2 years, especially given the time it takes CMake versions
 included in older distro releases to fall out of common use.

Yes, I fully agree, 2 years would be quite quite short.
The buildsystem should do its job, and not get in the way and create 
additional work.
I love that cmake still works on old projects, and doesn't fail when updating. 
I can remember all the hassle with autotools if some versions did not match, 
and I'm so happy that this is just not the case with cmake.

We have a lot of feature and time pressure at work (I guess most people around 
have that), and not having to babysit the cmake code for a long time is great.

If the conclusion would be a policy is removed after 5 years, it's deadline 
could even be part of the error/warning message right from the point when it 
is introduced (you are relying on CMP1234 OLD behaviour. This will be removed 
June 2020.).

Then I could (at work) ignore this maybe until 2017 or 2018, and then it would 
slowly rise in my priority, and at some point I would fix it in some spare 
time.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2015-03-23 Thread Alexander Neundorf
On Sunday, March 15, 2015 18:00:25 Nils Gladitz wrote:
 On 15.03.2015 16:42, Tobias Hunger wrote:
  Hi Peter,
  
  CMake does know all the headers or it could not decide which files
  need rebuilding.
 
 The build system that CMake generates knows the header dependencies and
 decides when which files need rebuilding.
 CMake itself doesn't know. How header dependencies are determined and
 where and how they are recorded is generator specific.

I have spent enough time on this code, so:
nitpicking
for the makefile-generators, the header dependencies are generated by cmake 
(not at cmake time, but at build time), which results in the depend.make file.
/nitpicking

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2015-03-14 Thread Alexander Neundorf
On Saturday, March 14, 2015 09:40:41 Peter Kümmel wrote:
 On 12.03.2015 16:24, Tobias Hunger wrote:
  A list of *all* headers used during the building of the target would
  be fine. There is no need to filter that list down in any way.
  
  CMake has that information: Without it cmake could not possibly know
  when a cpp file needs rebuilding. It would not be as successful a
  build system when it did not know that:-)
 
 Even cmake does not know all headers need for compilation, this is done
 by the compiler providing the dependency files.

the cmake dependency scanning does find all (and potentially some more) used 
headers, see depend.internal in the CMakeFiles/ tree.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2015-03-11 Thread Alexander Neundorf
On Wednesday, March 11, 2015 11:10:30 Stephen Kelly wrote:
 Hi,
 
 Following from the thread here:
 
  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu
 s=12394
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focu
 s=12650
 
 I'm starting to gather requirements and make sure the feature is
 well designed to satisfy the needs we're already aware of, and fits with
 the features CMake currently has.
 
 The aim is to generate a structured file containing metadata relating the
 buildsystem.
 
 To help with completing the design of this feature, I've written
 documentation (documentation driven design), and a unit test
 containing a CMakeLists.txt file which exercises many modern CMake
 features in the generate-metadata branch in my clone.
 
 Mostly the design I propose can be read in the documentation I wrote. I'm
 interested in any feedback.
 
  https://gitorious.org/cmake/steveires-cmake/source/generate-metadata:Tests/
 Metadata/CMakeLists.txt
 http://www.steveire.com/cmake-future/manual/cmake-metadata-generation.7.htm
 l
 
 I expect to require a few iterations to figure out what the metadata files
 should contain in the end.  Note that there are already some differences
 between my design and Aleix's implementation, such as that my design
 proposes one metadata file per config. There are also some things
 missing like location, because it is not yet clear to me whether build
 or install locations are needed etc.
 
 The content of the metadata file is determined by the build properties, and
 is necessarily similar to the compile-related content created when
 generating the actual buildsystem.  It additionally contains information
 about the output locations of build artifacts and information relating to
 the cmake description itself.
 
 Goals include:
 
 * Make it possible for IDEs to access the compile-related information for
   autocompletion and code navigation etc purposes.
 
 * Remove the need for IDEs to parse generated Makefiles or Ninja files to
   access compile-related information.  The structure of those files is not
   'stable', while the content of the metadata file is stable.
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412
 
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus
 =11081
 
 * Remove the need for users to create a new build directory and new build
   in order to use or switch IDEs.  QtCreator requires that
   the C::B 'extra generator is used as it parses compile information from
   that.  Other 'extra generators' such as for eclipse, sublime, kate etc
   also require fresh/new build directories, although the actual buildsystem
   they create is identical (assuming using all Makefile based or
   all Ninja based 'extra generators')

From my POV, the json metadata is just another extra generator, but one 
which can be always enabled additionally to other generators.
You say that users don't need new build directories for switching IDEs, but 
this is only under the assumption that the different IDEs will actually start 
to use this new file format.
See, users can use the C::B format and switch between CodeBlocks and 
QtCreator. If KDevelop and Kate would get plugins to read the C::B format 
(which is technically entirely possible) their users also would't have to 
create a new build directory.
So instead of adding generators to cmake which generate what the IDEs expect, 
this is a change, now cmake will generate a file and the IDEs are expected to 
follow.

My 2 cents
Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2015-02-16 Thread Alexander Neundorf
On Monday, February 16, 2015 21:31:45 Aleix Pol wrote:
 On Sat, Feb 14, 2015 at 1:02 PM, Stephen Kelly steve...@gmail.com wrote:
  Aleix Pol wrote:
  Hi guys,
  It's been since August with this. I understand we're all busy but this
  step is important for KDevelop as well as for other IDE's and I
  wouldn't like this to rot.
  
  Please, let's keep it moving forward.
  
  As far as I'm aware, it needs to move forward from this point:
   http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/fo
   cus=12151 
  I'm not certain the design is finished (eg what the file should contain
  now
  or eventually). I asked for tests/documentation as a way to trigger
  getting
  the design finished. Having either would give us a list of use-cases and
  we
  would know what's in scope and what's not in scope (eg whether compile
  options/link options are in scope and why).
 
 I can look further into documentation, if that's what holding us back.
 
  Another question: do you have any opinion about whether this should be one
  global file or one file per directory? I don't know - it seems like
  something that might or might not be relevant for tooling. Is the size of
  the generated file a consideration?
 
 I think the best is to have it all in 1 directory. You don't really
 want to have watchers on many files over there.
 
  How well does this feature work with large projects like VTK or a combined
  build of LLVM/Clang/lldb/libcxx/other ll projects.
 
 I just generated the file for LLVM: https://paste.kde.org/pxl8ozwah
 It's a 127KiB file, I don't think it's too mental considering it's a
 330 MiB repository.

I didn't follow the whole thread, just a few quick questions from looking at 
the file:


{
   name: obj2yaml,
   type: EXECUTABLE,
   configs: [
  ],
   directory: /home/kde-devel/tmp/llvm/build/bin,
   location: /home/kde-devel/tmp/llvm/build/bin/obj2yaml,
   backtrace: [/home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:452,
 /home/kde-devel/tmp/llvm/cmake/modules/AddLLVM.cmake:485,
 /home/kde-devel/tmp/llvm/tools/obj2yaml/CMakeLists.txt:6],
   installed: true
},


I guess name is the name of the target, type, configs, location, backtrace 
and installed seem to be clear.

What about directory ?
This is not the build dir where the target is defined (i.e. 
cmake_binary_dir(llvm/tools/obj2yaml/), is it ?
This directory would seem useful to me, e.g. you can run make help there to 
get the list of targets to compile/assemble/preprocess the files for that 
target. Or you can run the clean-script for that target.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2015-01-02 Thread Alexander Neundorf
On Tuesday, December 23, 2014 01:30:58 Aleix Pol wrote:
 On Thu, Sep 25, 2014 at 9:14 AM, Anton Makeev
...
  * No progress indication. Since the generation may take several minutes,
  
providing feedback is crucial.
 
 I never found such case, I would argue that a project which has a
 cmake script that takes several minutes is broken, but maybe we can
 open a thread to discuss it?

On network file systems things can get slow... (even if the file system feels 
really fast in general usage, i.e. has high data throuhgput).

...
  * Not sure if it’s possible at all - a lightweight phase where CMake only
  
collects necessary information (list of files/targets, compiler
settings).
This will help IDE react to the changes much faster.
 
 That would be extra-cool, agreed. Maybe it's an iteration we can
 consider in the future.


Yes, this would be cool, but until now whenever I thought about this my 
conclusion was that this is unfortunately not possible, since the 
targets/files/etc. can depend on anything, if() clauses, execution of 
commands, results of find_package(), etc.
 
Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Was AUTOMOC designed to run for each build?

2014-09-26 Thread Alexander Neundorf
On Friday, September 26, 2014 01:53:35 Stephen Kelly wrote:
 Alexander Neundorf wrote:
  I don't see why the target is executed each time, but is it that way by
  design?
  
  iirc, yes.
  The moc files have to be generated before any of the source files is
  compiled, so automoc is in a target the actual target depends on.
  IIRC it is exclude_from_all so that it is only built when the actual
  target is built.
  Do you think it should only rerun if any of the source files has changed ?
  There was some problem with this.
  The headers are usually not part of the listed source files.
 
 Hmm, well, we do know which header is relevant right? Because it's the one
 (or many) we set up commands to run moc on. Maybe we only know the relevant
 headers too late (at the time of running the -E cmake_autogen command, not
 at cmake time)?
 
 Something else I've wondered is why the parsing of the files is done
 'delayed' with the -E cmake_autogen command. Is it just to avoid doing that
 task during cmake time (because it's time consuming), and to allow
 parallelization?

it can't be done at cmake time, because editing a cpp file and inserting 
#include foo.moc does not cause cmake to rerun, so the parsing must happen 
during buildtime.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2014-09-25 Thread Alexander Neundorf
On Thursday, September 25, 2014 07:14:38 Anton Makeev wrote:
...
 Here is why I think the discussed functionality should not be a separate
 generator:
 
 CLion doesn’t have it’s own project model nor is intended as build tool
 replacement. Currently, the only option for CLion users is makefiles build,
 that is not a best option for everyone: there is a good and fast
 alternative ‘Ninja’. Ideally, users should be able to choose whatever tool
 better suites them.
 
 The problem is that the generated Makefiles are used both, for internal
 needs, like reading project structure, and also to build and run the user’s
 program. If we wanted to support Ninja generator, we would need to rewrite
 all the logic that retrieves the project information, using the files that
 are created by Ninja generator. While I suppose it’s possible, it’s not the
 best option - very error prone and resource demanding.
 
 If CMake generated a separate descriptor, regardless the generator used
 (Makefiles, Ninja), it would be much easier to support; and the users will
 benefit from better, more reliable and faster CMake integration in an IDE.

not sure I fully understand, but it seems you are maybe not aware how the 
extra generators in cmake work.

Those are basically run additionally to a normal generator. I.e. cmake 
generates makefiles or ninja files, and additionally project files for an IDE. 
This project file typically contains the list of targets, and for each target 
the build command. At that point it doesn't matter much anymore for the IDE 
whether the main generator is make or ninja.
This is implemented with the Eclipse generator, the CodeBlocks generator and 
the Kate generator. They all write a project file for the IDE additionally to 
the makefiles/ninja files for the actual building.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Was AUTOMOC designed to run for each build?

2014-09-23 Thread Alexander Neundorf
On Tuesday, September 23, 2014 09:58:58 Stephen Kelly wrote:
 Hi (especially Alex),
 
 I noticed that the automoc target is run each time, even for a trivial
 project:
 
  cmake_minimum_required(VERSION 2.8)
  project(automoctest)
 
  set(CMAKE_AUTOMOC ON)
 
  find_package(Qt5Widgets REQUIRED)
 
  add_executable(main main.cpp)
  target_link_libraries(main Qt5::Widgets)
 
 Each time I run make I get
 
  [ 33%] Automatic moc for target main
  /path/to/cmake -E cmake_autogen /path/to/build/CMakeFiles/main_automoc.dir/
 
 
 I checked CMake 2.8.7 and it executes the target each time too.
 
 In the implementation, makefile-AddUtilityCommand is called with 'true' to
 set the excludeFromAll parameter.
 
 I don't see why the target is executed each time, but is it that way by
 design?

iirc, yes.
The moc files have to be generated before any of the source files is compiled, 
so automoc is in a target the actual target depends on.
IIRC it is exclude_from_all so that it is only built when the actual target is 
built.
Do you think it should only rerun if any of the source files has changed ?
There was some problem with this.
The headers are usually not part of the listed source files. I would have to 
check to find out the details again.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2014-09-21 Thread Alexander Neundorf
On Friday, September 19, 2014 21:53:40 Alexander Neundorf wrote:
 On Friday, September 19, 2014 13:44:45 Brad King wrote:
 ...
 
  * Don't IDEs want to know the list of source files so they can
  
be used for editing?
  
  I haven't looked at what the Extra generators produce in a
  while but since they are meant for IDEs they would be a good
  reference for the information needed.
 
 typically a list of targets, the command to build each target, source files
 for each target, used include dirs and defines (-D) for code completion.
 
  However, AFAIK there
  is not an extra generator for a multi-config generator.
 
 Yes.

also after reading the other replies, I still don't understand why this 
shouldn't be a generator.
If I understand correctly, this is for people who simply run cmake and later 
on want to use kdevelop on the existing build tree.

How about simply adding support for an environment variable like 
CMAKE_GENERATOR, which, when set, will be used as generator as long as no 
other generator has been set via -G ?
KDE developers could set this variable, still run their build scripts, and 
later on use kdevelop.

I have a hard time imagining a user who uses let's say Eclipse with the 
Eclipse generator, who then suddenly wants to use kdevelop on his build tree.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2014-09-19 Thread Alexander Neundorf
On Friday, September 19, 2014 13:44:45 Brad King wrote:
...
 * Don't IDEs want to know the list of source files so they can
   be used for editing?
 
 I haven't looked at what the Extra generators produce in a
 while but since they are meant for IDEs they would be a good
 reference for the information needed. 

typically a list of targets, the command to build each target, source files 
for each target, used include dirs and defines (-D) for code completion.

 However, AFAIK there
 is not an extra generator for a multi-config generator.

Yes.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] Gold standard find module?

2014-09-10 Thread Alexander Neundorf
On Wednesday, September 10, 2014 10:38:44 Richard Shaw wrote:
 On Wed, Sep 10, 2014 at 7:18 AM, David Cole dlrd...@aol.com wrote:
   In this case just the one. I'm not that ambitious as I'm just
   volunteering my time to various FOSS projects and still have to
   maintain a day job to pay the bills!
  
  In that case, I would recommend just getting it into shape so that it
  works best for you. (But then, that's the way we've ended up with so
  many ways of doing things in the find modules we do have) As you
  submit changes for review, though, hopefully the reviewers will catch
  anything that is not recommended and ask you to revise it before
  pushing it into 'master'.
 
 That's kinda what I was thinking as well but some of the problem I'm trying
 to fix are requiring some significant changes that looking at a simple diff
 may not really be helpful...
 
  I think asking specific questions when you have something you're not
  sure of is better than trying to identify a gold standard find module
  on which to model your contributions.
 
 I'm sure I'll still have plenty of questions, I was just hoping to have a
 really good example to go by to catch the easy stuff.

Just a few things:
- variables should be named ExactCaseName_SOMETHING
- try to detect the version number
- use find_package_handle_standard_args() in the new mode
- make sure it works also on systems without pkg-config


Alex


-- 

Powered by www.kitware.com

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

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

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

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

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


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

2014-09-03 Thread Alexander Neundorf
On Wednesday, September 03, 2014 12:30:21 Aleix Pol wrote:
 On Tue, Sep 2, 2014 at 3:58 PM, David Cole dlrd...@aol.com wrote:
  It makes sense. But what IDE are you referring to? Eclipse? Some other
  concrete example? Or just any IDE and this feature should work everywhere
  CMake works...?
 
 I'm working on KDevelop, I know for a fact though, that other IDEs are
 looking for something similar too, such as QtCreator.

I still don't understand why this shouldn't be an additional ExtraGenerator.
It will generate a special file intended to be used by KDevelop and maybe 
QtCreator additionally to makefiles/ninja files. Could be called GenericJSON 
or so.
Other IDEs which don't support this file type but which need their own project 
file obviously still need their own specific generator.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2014-09-02 Thread Alexander Neundorf
On Tuesday, September 02, 2014 09:58:37 David Cole via cmake-developers wrote:
 It makes sense. But what IDE are you referring to? Eclipse? Some other
 concrete example? Or just any IDE and this feature should work
 everywhere CMake works...?

AFAIK it is kdevelop4, and the goal is that developers don't have to tell 
cmake to run a kdevelop4 generator, but just the normal makefile generator, 
and still be able to use kdevelop4 on these build trees.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


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

2014-09-01 Thread Alexander Neundorf
On Monday, September 01, 2014 15:26:12 David Cole via cmake-developers wrote:
 The approach looks reasonable, but having it unconditionally spit out a
 file in cmGlobalGenerator regardless of generator is probably not what
 we want. Seems like it should be based on a variable, or be in a
 specific generator, or somehow have a limited scope.

I agree. IMO this should be a generator, I don't see why it should work around 
that.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] find_package() verbosity

2014-08-26 Thread Alexander Neundorf
On Tuesday, August 26, 2014 10:41:04 Nils Gladitz wrote:
 Are there any official recommendations or opinions on how verbose a find
 module (or package configuration file) should be on success?
 
 - Find modules using FindPackageHandleStandardArgs report success once.
 
 - FindBoost.cmake reports success every time.
 
 - Qt5 package configuration files (and find_package() in CONFIG mode
 specifically) keep quiet on success.

I think the recommendation is to report when it fails, and whenever something 
changes in the successful result, i.e. on the first success and potentially if 
on a later run some additionaly module or something has been found. IOW what 
FindPackageHandleStandardArgs.cmake does.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] What about #line like feature in cmake language?

2014-05-22 Thread Alexander Neundorf
On Thursday, May 22, 2014 09:16:17 Brad King wrote:
 On 05/21/2014 04:05 PM, Nicolas Desprès wrote:
  at the time the AST node is created the file location is frozen.
  Locations are controlled by the lexer so do comments.
 
 Correct.  This has to be done by the lexer.  We already have
 documentation blocks that are indistinguishable from comments:
 
  #.rst:
  # ...reStructuredText docs...
 
  #[=[.rst:
  ...reStructuredText docs...
  #]=]
 
 I see no reason this can't be used for #line too:
 
  #.cmake-source-line: 1234 /path/to/real/file
 
 In all of the above cases there is no semantic meaning to the
 comments as far as the CMake language processor is concerned.
 The last case only changes the file names and line numbers in
 backtraces.
 
 One remaining challenge is CMAKE_CURRENT_LIST_FILE and
 CMAKE_CURRENT_LIST_LINE. 

Probably also CMAKE_CURRENT_LIST_DIR.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] dpkg-shlibdeps

2014-05-19 Thread Alexander Neundorf
On Monday, May 19, 2014 13:06:17 Kornel Benko wrote:
 Am Montag, 19. Mai 2014 um 12:59:31, schrieb Nils Gladitz
 nilsglad...@gmail.com
  On 05/19/2014 12:50 PM, Kornel Benko wrote:
   I am using CPACK with
   
 set(CPACK_DEBIAN_PACKAGE_DEBUG ON)
   
   There is one offending output
   
 CPackDeb Debug: dpkg-shlibdeps version is 
   
   Looking into CPackDeb.cmake, the regex for getting the version
   searches 'dpkg-shlibdeps version ([0-9]+\\.[0-9]+\\.[0-9]+)'
   from output of 'dpkg-shlibdeps --version'.
   
   But in my case (ubuntu 12.10), this is not matching, since the command
   returns  
 'Debian dpkg-shlibdeps Version 1.16.7.
 ...'
   
   Could the regex please be replaced by
   
 'dpkg-shlibdeps [vV]ersion ([0-9]+\\.[0-9]+\\.[0-9]+)'
   
   ?
   
   This is cmake version 3.0.20140511-g17c650
  
  Looks like the whole string is localized
  e.g. Norwegian: Debian %s versjon %s.\n.
 
 Yes, you are right. My localization was German.
 
  Perhaps the whole non numeric prefix should be skipped.
 
 +1

I guess the locale should be reset before calling the executable.
That's what's done also in other places.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] CMP0043 warnings everywhere

2014-04-29 Thread Alexander Neundorf
On Monday, April 28, 2014 10:26:56 James Bigler wrote:
  -Original Message-
  From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On
  Behalf Of Brad King
  Sent: Wednesday, April 23, 2014 11:06 AM
  To: cmake-developers@cmake.org
  Subject: Re: [cmake-developers] CMP0043 warnings everywhere
  
  On 04/23/2014 12:57 PM, James Bigler wrote:
   I'm getting tons of CMP0043 warnings on my existing project.
   
   I have cmake_policy(VERSION 2.6) set in my project.
   Why am I being pestered by warnings?  Shouldn't I get a policy value
   appropriate for 2.6 (so CMP0043 should be set to OLD)?
  
  Setting policies by VERSION leaves policies newer than that version unset,
  not set to OLD.  If it were to set them to OLD then no new policies would
  ever warn. There is intentionally no way to turn off warnings about
  policies newer than those known to the project code, except by using
  -Wno-dev locally. Otherwise developers would never see the warnings and
  know to update their code.
 
 I thought the purpose of policies was to keep some backward compatibility
 feature, but allow users to select the new behavior.  In this case, setting
 the behavior for new policies to OLD seems the most logical, especially
 when I asked for it with cmake_policy(VERSION).  Now I'm forced to set this
 policy to OLD in order to not have a million warnings spam my team. 

if(POLICY CMP0043)
   cmake_policy(SET CMP0043 OLD)
endif()

you might wrap that into a macro, so you just hand in the list of (new) 
policies.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] CMP0043 warnings everywhere

2014-04-29 Thread Alexander Neundorf
On Monday, April 28, 2014 13:39:09 Brad King wrote:
 On 04/28/2014 01:26 PM, James Bigler wrote:
  I thought the purpose of policies was to keep some backward compatibility
  feature, but allow users to select the new behavior.
 
 The purpose is to change CMake interfaces or behavior while still
 building existing project releases that have not been updated by
 their developers to understand the new behavior:
 
  http://www.cmake.org/Wiki/CMake/Policies
 
  Now I'm forced to set this policy to OLD in order to not have a million
  warnings spam my team.
 
 Or, you could fix your project to not use the behavior deprecated
 by the policy.  

Other reasons are e.g. avoiding to annoy your developer team by warnings which 
don't matter (the build has been working, so there's no need to change it).

Or, correct me if I'm wrong, isn't it possible that by fixing a warning the 
project then requires the cmake version which added the warning ?
Which would mean fixing the warning would break the build with the (old) 
required cmake version ?

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] cmake --find-package

2014-04-26 Thread Alexander Neundorf
On Friday, April 25, 2014 12:10:30 Alan W. Irwin wrote:
 On 2014-04-24 22:41+0200 Alexander Neundorf wrote:
  On Wednesday, April 23, 2014 14:45:45 Alan W. Irwin wrote:
  On 2014-04-23 22:40+0200 Alexander Neundorf wrote:
  On Wednesday, April 23, 2014 13:21:39 Alan W. Irwin wrote:
  On 2014-04-23 13:21-0400 Bill Hoffman wrote:
  On 4/23/2014 12:22 PM, Alan W. Irwin wrote:
  However, if you discover the problem is a general one for
  --find-package and Qt5, then it appears that Qt5 might be a good
  illustrative example to use for your renewed effort at developing a
  reliable --find-package capability.
  
  I recently ran into a project using --find-package and found a
  limitation
  that could be very problematic.  If a find module in CMake uses a
  try-compile, or tries to figure out anything to do with the compiler,
  this
  command will fail.I am not sure there is a good way around this.
  Certainly try-compile is not actively discouraged in the CMake
  Modules,
  so
  this can be added to any module at any time, breaking --find-package
  in
  the
  future.
  
  Hi Bill:
  
  You cannot use --find-package unless you specify the language.  So I
  assume that --find-package enables the specified language, and, in
  general, you would think that try-compile would work properly under
  those circumstances.
  
  No.
  
  It doesn't really enable a language, it only loads a bunch of files to
  set
  the most urgently required variables.
  Most of it is implemented in CMakeFindPackageMode.cmake
  
  It is basically wrapping a find_package() call, setting up just enough
  to
  make it succeed usually.
  try_compile() will fail.
  
  My plan was to limit this mode to Config.cmake files only, but as I
  said,
  due to the changes in CMake this has become too much work, so I won't
  work on that in the forseeable future.
  
  Hi Alex:
  
  The question that remains is will --find-package be maintained
  indefinitely for CMake-3.x?
  
  I can't guarantee.
  Since modern Config.cmake files don't follow the old convention of setting
  a _LIBRARIES and a _INCLUDE_DIRS variable anymore, which is the basic
  assumption the --find-package feature was based on, I don't really feel
  motivated to fix this.
  
  As I said, --find-package is the only way
  I know how to obtain required compile and link flags for Qt5 at the
  present time (assuming the patch for the library name screwup is
  accepted for the CMake support files in Qt5, but that is a separate
  Qt5 issue compared to whether or not you decide to maintain
  --find-package for CMake-3.x).  Until I discovered this thread, I had
  assumed that the --find-package option would be maintained
  indefinitely for CMake so I haven't looked further at other
  alternatives yet.
  
  Assuming you or someone else decides to remove the --find-package
  capability now or sometime during CMake-3.x (which from my point of
  view makes sense if you are not going to maintain it),
  
  I wouldn't object.
  This is actually the first time I get serious feedback for that feature, I
  had the impression nobody uses it or considers it useful.
 
 Hi Alex:
 
 I hadn't attempted to use this feature myself up to now because most
 of the PLplot build system was implemented long before --find-package
 was implemented.  But, in general, I think --find-package is an
 excellent idea since ideally (assuming try-compile is not used) it
 should supply users with the essential compile and link flags needed
 for a dependency while relieving them of the burden of figuring out
 details of the CMake-based build system for that dependency.  That's a
 large potential benefit for a typical modern project that might have
 say 20 or more dependencies.
 
 Much earlier in this thread you said the
 
 following:
   A new, similar --find-target mode or similar may be more
 
 appropriate:
cmake --find-target --package Qt5Widgets --target Qt5::Widgets ...

# KF5Config exports 3 independent targets:
cmake --find-target --package KF5Config --target KF5::ConfigCore
 
 ...
 
cmake --find-target --package KF5Config --target KF5::ConfigGui
 
 ...
 
cmake --find-target --package KF5Config --target KF5::ConfigWidgets
...
   
   Yes, that will work.
   And a new command/option is not even necessary.
   The name of the target could be given as additional option.
   If none is given, it will use the variables as it does now, if a
 
 target is
 
   given, it will use this target and its properties.
   
   I'll work on that when I find the time (and nobody is faster).
 
 Since then you have apparently changed your mind about working on this
 (which I can completely understand; I also have very limited time I
 can work on CMake).  But I have one important follow-up question for
 you.
 
 Is it actually straightforward (but tedious) to implement a
 translation of target properties into ordinary compile and link flags
 without detailed knowledge of which target properties have been used

Re: [cmake-developers] cmake --find-package

2014-04-24 Thread Alexander Neundorf
On Wednesday, April 23, 2014 14:45:45 Alan W. Irwin wrote:
 On 2014-04-23 22:40+0200 Alexander Neundorf wrote:
  On Wednesday, April 23, 2014 13:21:39 Alan W. Irwin wrote:
  On 2014-04-23 13:21-0400 Bill Hoffman wrote:
  On 4/23/2014 12:22 PM, Alan W. Irwin wrote:
  However, if you discover the problem is a general one for
  --find-package and Qt5, then it appears that Qt5 might be a good
  illustrative example to use for your renewed effort at developing a
  reliable --find-package capability.
  
  I recently ran into a project using --find-package and found a
  limitation
  that could be very problematic.  If a find module in CMake uses a
  try-compile, or tries to figure out anything to do with the compiler,
  this
  command will fail.I am not sure there is a good way around this.
  Certainly try-compile is not actively discouraged in the CMake Modules,
  so
  this can be added to any module at any time, breaking --find-package in
  the
  future.
  
  Hi Bill:
  
  You cannot use --find-package unless you specify the language.  So I
  assume that --find-package enables the specified language, and, in
  general, you would think that try-compile would work properly under
  those circumstances.
  
  No.
  
  It doesn't really enable a language, it only loads a bunch of files to set
  the most urgently required variables.
  Most of it is implemented in CMakeFindPackageMode.cmake
  
  It is basically wrapping a find_package() call, setting up just enough to
  make it succeed usually.
  try_compile() will fail.
  
  My plan was to limit this mode to Config.cmake files only, but as I said,
  due to the changes in CMake this has become too much work, so I won't
  work on that in the forseeable future.
 
 Hi Alex:
 
 The question that remains is will --find-package be maintained
 indefinitely for CMake-3.x?  

I can't guarantee.
Since modern Config.cmake files don't follow the old convention of setting a 
_LIBRARIES and a _INCLUDE_DIRS variable anymore, which is the basic assumption 
the --find-package feature was based on, I don't really feel motivated to fix 
this.

 As I said, --find-package is the only way
 I know how to obtain required compile and link flags for Qt5 at the
 present time (assuming the patch for the library name screwup is
 accepted for the CMake support files in Qt5, but that is a separate
 Qt5 issue compared to whether or not you decide to maintain
 --find-package for CMake-3.x).  Until I discovered this thread, I had
 assumed that the --find-package option would be maintained
 indefinitely for CMake so I haven't looked further at other
 alternatives yet.
 
 Assuming you or someone else decides to remove the --find-package
 capability now or sometime during CMake-3.x (which from my point of
 view makes sense if you are not going to maintain it), 

I wouldn't object.
This is actually the first time I get serious feedback for that feature, I had 
the impression nobody uses it or considers it useful.

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] cmake --find-package (was: Roadmap to CMake 3.0)

2014-04-23 Thread Alexander Neundorf
On Wednesday, April 23, 2014 09:22:09 Alan W. Irwin wrote:
 On 2013-10-19 20:16+0200 Alexander Neundorf wrote:
  On Thursday 17 October 2013, Stephen Kelly wrote:
  Brad King wrote:
  On 10/17/2013 04:58 PM, Alexander Neundorf wrote:
  Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES
  variable (or a slight variation) being set after a successful
  find_package(Foo):
  http://lists.kde.org/?l=kde-core-develm=138198795723680w=2 I.e. in
  the
  future there will be Find-modules which typically export one of
  (Foo|FOO)_(LIBRARIES|LIBRARY), some Config.cmake files which do that
  too, and a big number, probably majority, of Config.cmake files, which
  do not export such variables.
  
  The only chance I see would be to simply collect all library targets
  and
  return what they provide, but this doesn't feel good. I would have much
  prefered using a clear interface like the Foo_LIBRARIES variable.
  
  Perhaps we need to establish a convention for find modules and package
  configuration files to interact with --find-package mode.  I have no
  thoughts on the specifics of how that would work though.
  
  A new, similar --find-target mode or similar may be more appropriate:
   cmake --find-target --package Qt5Widgets --target Qt5::Widgets ...
   
   # KF5Config exports 3 independent targets:
   cmake --find-target --package KF5Config --target KF5::ConfigCore ...
   cmake --find-target --package KF5Config --target KF5::ConfigGui ...
   cmake --find-target --package KF5Config --target KF5::ConfigWidgets ...
  
  Yes, that will work.
  And a new command/option is not even necessary.
  The name of the target could be given as additional option.
  If none is given, it will use the variables as it does now, if a target is
  given, it will use this target and its properties.
  
  I'll work on that when I find the time (and nobody is faster).
 
 How is that going, Alex?

I have more or less given up on this.
Due to all the changes in cmake recently (not recommending setting variables 
anymore in find_package(), and all the target property stuff), this would 
require quite some work, and I seriously don't have that much time for cmake 
currently.
Also, one of the big benefits, not having to read documentation for every 
package anymore, but having a standard interface, is lost, AFAICS.

So, if somebody wants to pick that up, feel free.

Sorry
Alex

-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] cmake --find-package

2014-04-23 Thread Alexander Neundorf
On Wednesday, April 23, 2014 13:21:39 Alan W. Irwin wrote:
 On 2014-04-23 13:21-0400 Bill Hoffman wrote:
  On 4/23/2014 12:22 PM, Alan W. Irwin wrote:
  However, if you discover the problem is a general one for
  --find-package and Qt5, then it appears that Qt5 might be a good
  illustrative example to use for your renewed effort at developing a
  reliable --find-package capability.
  
  I recently ran into a project using --find-package and found a limitation
  that could be very problematic.  If a find module in CMake uses a
  try-compile, or tries to figure out anything to do with the compiler, this
  command will fail.I am not sure there is a good way around this.
  Certainly try-compile is not actively discouraged in the CMake Modules, so
  this can be added to any module at any time, breaking --find-package in
  the
  future.
 
 Hi Bill:
 
 You cannot use --find-package unless you specify the language.  So I
 assume that --find-package enables the specified language, and, in
 general, you would think that try-compile would work properly under
 those circumstances.

No.

It doesn't really enable a language, it only loads a bunch of files to set the 
most urgently required variables.
Most of it is implemented in CMakeFindPackageMode.cmake

It is basically wrapping a find_package() call, setting up just enough to make 
it succeed usually.
try_compile() will fail.

My plan was to limit this mode to Config.cmake files only, but as I said, due 
to the changes in CMake this has become too much work, so I won't work on that 
in the forseeable future.

Alex


-- 

Powered by www.kitware.com

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

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

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

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

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


Re: [cmake-developers] New EVIS parser moving forward (3.1)

2014-02-23 Thread Alexander Neundorf
On Friday, February 21, 2014 14:32:18 Brad King wrote:
 On 02/21/2014 02:18 PM, Jean-Christophe Fillion-Robin wrote:
  If possible, not having implicit expansion for quoted argument
  would be great at make things more intuitive and practical.
 
 This has been discussed before.  It will take some refactoring
 of the CMake language command processing implementation to
 tell commands, like if(), about the delimiters used for each
 argument: unquoted, quoted, or bracket arguments. 


Yes.
A simple stupid way to fix the problem for STREQUAL would be to add an 
alternative comparison operator to if(), which never expands variables, and 
leave STREQUAL as it is. E.g.

if (${Foo} == Bar)

No risk, easy to do, no backwards compatibility issues, but somewhat ugly, as 
was concluded the last time this was discussed here.

Alex

-- 

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] Request for review of topic intel-visibility

2014-02-07 Thread Alexander Neundorf
On Friday, February 07, 2014 05:33:47 PM Stephen Kelly wrote:
 Nils Gladitz wrote:
  On 02/07/2014 04:24 PM, Brad King wrote:
  This looks correct to me and is a good bug fix.  Please merge
  to 'next' for testing.
  
  Thanks, will do!
  
  Do you have access to Intel C/C++ on OS X that you could use to try
  this task?
  
  I currently only have access to Intel on Windows which is why I thought
  it safer to put the topic up for review first too.
 
 Does intel on windows have separate gcc-like and msvc-like modes?

 Alex also adjusted the intel handling of -isystem today. Does that work if
 the direct preprocessor flag -Wp,-isystem, is used, if there's some

Would there be an advantage compared to using -isystem ?
AFAIK -isystem is not supported by icpc under Windows, and from looking at 
other files in cmake -isystem seems in general not to be supported under OSX.
But I have access only to icpc under Linux, so I can't check.

Alex

-- 

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-28 Thread Alexander Neundorf
On Tuesday 28 January 2014, Brad King wrote:
 On 01/23/2014 04:08 PM, Alexander Neundorf wrote:
  Any more comments left ?
 
 Moving the discussion from
 
  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9156/focu
 s=9158
 
 back to the thread where it belongs:
 
 On 01/27/2014 04:58 PM, Stephen Kelly wrote:
  Though I still don't like the behavior in the topic with project()
  commands without a specified VERSION and the
  CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND variable etc. I don't see
  why all the complexity is needed.
  
  From what I understand, the reason it was added is related to using
  add_subdirectory to add a self-contained/standalone project to host
  buildsystem.
 
 My main concern that the VERSION complexity solves is for changing
 behavior of existing projects that are *not* modified at all.  We've
 established that a project() without VERSION needs to unset the
 PROJECT_VERSION variables because otherwise they would not correspond
 to the current PROJECT_NAME.  However, an existing project could do
 
  # CMakeLists.txt
  project(Top)
  set(PROJECT_VERSION 1.0.0)
  add_subdirectory(Sub)
 
  # Sub/CMakeLists.txt
  project(Sub)
  message(STATUS Top version = ${PROJECT_VERSION})
 
 Since previous versions of CMake documented no special behavior
 for the PROJECT_VERSION variable this code is completely fine
 now, but would suddenly change in behavior if project() started
 to unset PROJECT_VERSION.
 
 So our options are
 
 (1) Design new behavior in a way that requires a change to the
 project to activate.
 
 (2) Add a policy.  The policy should only trigger when the
 project() command is about to unset a PROJECT_VERSION
 variable that was set by user code and not by a previous
 project() command.


I think my current version fits (1).
If nothing is changed in a project, the behaviour will not change at all (if 
it does, I have overseen something).

Things only start to change once a VERSION is added to a project() call.
Then, if a following project() call without VERSION sees the PROJECT_VERSION 
variable set, and sees that CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND is 
set to TRUE, it unsets the PROJECT_VERSION.
This means it does not unset it if the user has manually set the variable and 
not added VERSION to any project() call.

The only condition where things will break (but still only after the user has 
actually modifed the project), is the following:

CMakeLists.txt:

project(Foo VERSION 1.2.3)

set(PROJECT_VERSION 4.5.6)

sub/CMakeLists.txt:

project(Bar)


IMO this is not the place for a policy, since the behaviour of the existing, 
unchanged project did not change, it is still working as it did before.

The issue above (which is probably unlikely), can be worked around by manually 
unsetting the guard variable:

CMakeLists.txt:
project(Foo VERSION 1.2.3)
unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)

set(PROJECT_VERSION 4.5.6)

sub/CMakeLists.txt:

project(Bar)

That's not too nice, but IMO a reasonable solution for fixing that hopefully 
rare error case.

Regarding (2): how should I detect whether PROJECT_VERSION has been set 
manually ?
I had some code which did that, but only if the version set via SET() was 
different than the version set via PROJECT(). I.e. it would work almost 
always, but in the cases where it wouldn't work, it would be very weird and 
hard to find. I don't think this would have been good behaviour.
Alternatively probably something could be done with variable_watch, but to me 
this seems a bit heavy for this purpose. I mean, it's only a rare breakage 
after a manual change to a project, and then all set() calls would be checked, 
always.

I still think what I merged into next is Ok.
I can add a few more test cases, no problem.
I asked for more comments last Thursday, and there were none until I merged 
into next on Saturday.

I know that it would have been nice to squash the two actual code commits into 
one...
I tried that two weeks ago or so, and I (or git, depending on how you see it) 
messed up my branches.
Asking google verified that squashing anything into the first commit of a 
branch is not really supported by git.
I didn't consider it worth it to try to follow the recipes suggested here 
http://stackoverflow.com/questions/598672/git-how-to-squash-the-first-two-
commits or in other places just to merge the two commits into one.
The history is not messy, it's just one commit which could have been squashed. 
But even as they are they are not really hard to read.

Alex
-- 

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-23 Thread Alexander Neundorf
On Monday 06 January 2014, Alexander Neundorf wrote:
 Hi,
 
 on cmake stage I have a simple branch AddVersionToProjectCommand.
 This extends the project command to also accept a version number:
 
 project(Foo VERSION 1.2.3 CXX)
 
 All that does is setting some more variables (beside PROJECT_NAME,
 PROJECT_SOURCE_DIR, PROJECT_BINARY_DIR and the projectName_...
 equivalents).
 
 When setting a version, you also get PROJECT_VERSION and
 PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK) variables as well as the
 projectName_... equivalents.
 
 These version variables can then be used in other commands/macros/functions
 which need a version.
 I modified write_basic_package_version_file() accordingly, so that you can
 now simply do
 
 project(Foo VERSION 1.2.3)
 
 ...
 
 write_basic_package_version_file(FooConfigVersion.cmake
  COMPATIBILITY AnyNewerVersion)
 
 and this will use the version number from the project() call automatically
 (if no VERSION has been given explicitely).


Ok, I force-pushed my AddVersionToProjectCommand branch again.
Documentation is fixed, and after Steves comment not to overdo it with 
protecting the user from its own changes I removed the check for the actual 
value of PROJECT_VERSION again, since I think in case this breaks something, 
this will be very weird for the user.

I'd like to merge that into next soon.

Any more comments left ?

Alex
-- 

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-22 Thread Alexander Neundorf
On Tuesday 21 January 2014, Stephen Kelly wrote:
 Alexander Neundorf wrote:
  On Sunday 19 January 2014, Stephen Kelly wrote:
  Alexander Neundorf wrote:
   This is now in the AddVersionToProjectCommand branch on git stage.
   
   Please have a close look at it.
  
  The documentation is not formatted correctly as rst.
  
  I looked at the generated html file, it seemed to look ok.
  What's wrong with it ?
 
 +# If no VERSION is given, the version number specified via
 +# project(... VERSION x.y.z ...) is used. If this hasn't been set, it
 errors
 +# out.
 
 ... to:
 
  specified via :command:`project(VERSION)`
 
 I didn't look for other problems or opportunities for better docs. I just
 noticed that, and it indicates you haven't looked into what can/should be
 done with rst yet. I suggest you look for those opportunities.

Ah, ok.

Is it actually recommended to use some formatting, like bold or italic or 
something else ?

Alex
-- 

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-20 Thread Alexander Neundorf
On Sunday 19 January 2014, Stephen Kelly wrote:
 Alexander Neundorf wrote:
  This is now in the AddVersionToProjectCommand branch on git stage.
  
  Please have a close look at it.
 
 The documentation is not formatted correctly as rst.

I looked at the generated html file, it seemed to look ok.
What's wrong with it ?

Alex
-- 

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-19 Thread Alexander Neundorf
On Wednesday 15 January 2014, Matthew Woehlke wrote:
 On 2014-01-15 16:25, Alexander Neundorf wrote:
  On Wednesday 15 January 2014, Alexander Neundorf wrote:
  And, to actually produce the breakage, at some place the VERSION
  argument must have been added.
  With the current state of my branch, this could be worked around by
  unsetting the guard variable:
  
  
  project(Foo VERSION 1.2.3)
  
  
  unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)
  add_subdir(B)
  
  This way B would be protected from that change in behaviour.
  
  I could also add more logic, to try to detect if PROJECT_VERSION has been
  set manually, e.g. project() could reset PROJECT_VERSION only if it has
  the same value as ${${ParentProjectName}_VERSION}. Then it would only
  break if there was a manual set(PROJECT_VERSION ...) before a project()
  call without VERSION, and if that manually set version was the same as
  the version in the parent project.
 
 IMHO your last suggestion (very good idea, btw!) is more than adequate,
 especially given the original weakness of my objection (which was
 always more along the lines of did you consider this case, and should
 we worry about it?).

This is now in the AddVersionToProjectCommand branch on git stage.

Please have a close look at it.

I'm not sure I like that somewhat magic behaviour how it decides whether to 
unset() the variables or not.
There will be problems with this very rarely, but when the circumstances 
occur, it may be quite hard to figure out.
I.e. it could happen when the version number of a sub-project changes, then 
suddenly PROJECT_VERSION could be empty afterwards:

CMakeLists.txt:

project(Parent VERSION 1.0.0)

add_subdirector(sub)

sub/CMakeLists.txt:
- set(PROJECT_VERSION 0.0.1)
+ set(PROJECT_VERSION 1.0.0)
  project(Foo)
  message(STATUS Version: ${PROJECT_VERSION})

Such a patch would have the effect that PROJECT_VERSION in suddenly empty in 
the message() call.

I would probably prefer to not touch the PROJECT_VERSION variables at all if 
VERSION is not used, then there are at least no (very rare) surprises or 
sudden breakages.

Alex
-- 

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-19 Thread Alexander Neundorf
On Sunday 19 January 2014, Alexander Neundorf wrote:
 On Wednesday 15 January 2014, Matthew Woehlke wrote:
  On 2014-01-15 16:25, Alexander Neundorf wrote:
   On Wednesday 15 January 2014, Alexander Neundorf wrote:
   And, to actually produce the breakage, at some place the VERSION
   argument must have been added.
   With the current state of my branch, this could be worked around by
   unsetting the guard variable:
   
   
   project(Foo VERSION 1.2.3)
   
   
   unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)
   add_subdir(B)
   
   This way B would be protected from that change in behaviour.
   
   I could also add more logic, to try to detect if PROJECT_VERSION has
   been set manually, e.g. project() could reset PROJECT_VERSION only if
   it has the same value as ${${ParentProjectName}_VERSION}. Then it
   would only break if there was a manual set(PROJECT_VERSION ...) before
   a project() call without VERSION, and if that manually set version was
   the same as the version in the parent project.
  
  IMHO your last suggestion (very good idea, btw!) is more than adequate,
  especially given the original weakness of my objection (which was
  always more along the lines of did you consider this case, and should
  we worry about it?).
 
 This is now in the AddVersionToProjectCommand branch on git stage.
 
 Please have a close look at it.
 
 I'm not sure I like that somewhat magic behaviour how it decides whether to
 unset() the variables or not.
 There will be problems with this very rarely, but when the circumstances
 occur, it may be quite hard to figure out.
 I.e. it could happen when the version number of a sub-project changes, then
 suddenly PROJECT_VERSION could be empty afterwards:
 
 CMakeLists.txt:
 
 project(Parent VERSION 1.0.0)
 
 add_subdirector(sub)
 
 sub/CMakeLists.txt:
 - set(PROJECT_VERSION 0.0.1)
 + set(PROJECT_VERSION 1.0.0)
   project(Foo)
   message(STATUS Version: ${PROJECT_VERSION})
 
 Such a patch would have the effect that PROJECT_VERSION in suddenly empty
 in the message() call.
 
 I would probably prefer to not touch the PROJECT_VERSION variables at all
 if VERSION is not used, then there are at least no (very rare) surprises
 or sudden breakages.
 
 Alex

I could maybe also do something with variable_watch(), but I haven't used this 
yet at all. It probably would have somne performance impact I guess.

Alex

-- 

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-15 Thread Alexander Neundorf
On Wednesday 15 January 2014, Matthew Woehlke wrote:
 On 2014-01-14 18:00, Alexander Neundorf wrote:
  On Tuesday 14 January 2014, Matthew Woehlke wrote:
  While that sounds good for 99.9% of cases, what about the case of
  project A that includes project B, where B is not updated, but A decides
  to start using project(...VERSION...). Now if B was using
  PROJECT_VERSION internally, it is broken. (Note that I'm implying that B
  is e.g. a separate repository that may not be as easy to update/fix as
  A.)
  
  You mean
  CMakeLists.txt:
  
  project(Foo VERSION 1.2.3)
  
  
  
  add_subdir(B)
  
  B/CMakeLists.txt:
  
  set(PROJECT_VERSION 4.5.6)
  project(Bar)
  
  
  Indeed.
  In that case, PROJECT_VERSION will be unset afterwards.
 
 Exactly. I wanted to point it out, but as that's probably unusual, I
 would be okay ignoring that case.
 
  If it would be
  
  B/CMakeLists.txt:
  
  
  project(Bar)
  set(PROJECT_VERSION 4.5.6)
  
  everything is fine.
 
 ...until B/C/CMakeLists.txt also calls project() :-). Basically, you
 (can) get into trouble if you update your project to use
 project(VERSION) and also have an external sub-project that tries to
 use PROJECT_VERSION. However, as much as folks¹ occasionally bleat about
 this use case (having an embedded external project), I suspect it's
 not actually very common², and anyway there is only a problem when the
 sub-project *also* uses PROJECT_VERSION (which I suspect is also rare in
 general, and more so the intersection of the two).
 
 Again, given the above, I've no objection to breaking that case, which
 may well only exist in the hypothetical sense with no 'in the wild'
 instances actually existing.

And, to actually produce the breakage, at some place the VERSION argument must 
have been added.
With the current state of my branch, this could be worked around by unsetting 
the guard variable:


project(Foo VERSION 1.2.3)


unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)
add_subdir(B)

This way B would be protected from that change in behaviour.

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

2014-01-15 Thread Alexander Neundorf
On Wednesday 15 January 2014, Alexander Neundorf wrote:
 On Wednesday 15 January 2014, Matthew Woehlke wrote:
  On 2014-01-14 18:00, Alexander Neundorf wrote:
   On Tuesday 14 January 2014, Matthew Woehlke wrote:
   While that sounds good for 99.9% of cases, what about the case of
   project A that includes project B, where B is not updated, but A
   decides to start using project(...VERSION...). Now if B was using
   PROJECT_VERSION internally, it is broken. (Note that I'm implying that
   B is e.g. a separate repository that may not be as easy to
   update/fix as A.)
   
   You mean
   CMakeLists.txt:
   
   project(Foo VERSION 1.2.3)
   
   
   
   add_subdir(B)
   
   B/CMakeLists.txt:
   
   set(PROJECT_VERSION 4.5.6)
   project(Bar)
   
   
   Indeed.
   In that case, PROJECT_VERSION will be unset afterwards.
  
  Exactly. I wanted to point it out, but as that's probably unusual, I
  would be okay ignoring that case.
  
   If it would be
   
   B/CMakeLists.txt:
   
   
   project(Bar)
   set(PROJECT_VERSION 4.5.6)
   
   everything is fine.
  
  ...until B/C/CMakeLists.txt also calls project() :-). Basically, you
  (can) get into trouble if you update your project to use
  project(VERSION) and also have an external sub-project that tries to
  use PROJECT_VERSION. However, as much as folks¹ occasionally bleat about
  this use case (having an embedded external project), I suspect it's
  not actually very common², and anyway there is only a problem when the
  sub-project *also* uses PROJECT_VERSION (which I suspect is also rare in
  general, and more so the intersection of the two).
  
  Again, given the above, I've no objection to breaking that case, which
  may well only exist in the hypothetical sense with no 'in the wild'
  instances actually existing.
 
 And, to actually produce the breakage, at some place the VERSION argument
 must have been added.
 With the current state of my branch, this could be worked around by
 unsetting the guard variable:
 
 
 project(Foo VERSION 1.2.3)
 
 
 unset(CMAKE_PROJECT_VERSION_SET_BY_PROJECT_COMMAND)
 add_subdir(B)
 
 This way B would be protected from that change in behaviour.

I could also add more logic, to try to detect if PROJECT_VERSION has been set 
manually, e.g. project() could reset PROJECT_VERSION only if it has the same 
value as ${${ParentProjectName}_VERSION}. Then it would only break if there 
was a manual set(PROJECT_VERSION ...) before a project() call without VERSION, 
and if that manually set version was the same as the version in the parent 
project.

Or, maybe, project() without VERSION should simply NOT clear PROJECT_VERSION.
Then it may be a somewhat inconsistent or not ideal behaviour, but OTOH there 
is zero chance for breaking an existing build by adding a VERSION somewhere.

Alex
-- 

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

2014-01-14 Thread Alexander Neundorf
On Tuesday 14 January 2014, Brad King wrote:
 On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
  does this require a policy now ?
  
  Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
  project(Foo)
  call in a subdir, which would now unset Foo_VERSION_MAJOR.
  The same for PROJECT_VERSION_MAJOR, but this is maybe less likely.
 
 I don't think project(Foo) needs to affect Foo_VERSION_* when no
 VERSION argument is given (but should handle empty VERSION ).
 It should still handle PROJECT_VERSION_* to ensure consistency
 with PROJECT_NAME.  That may need a policy, but it will be tricky
 because we need to know if the value came from a previous project()
 call or a user set() in order to know when to trigger compatibility.
 
 Perhaps project(... VERSION ...) can set some cmMakefile variable
 internally that says the project knows about versions so it is okay
 project(Foo) calls to unset them in subdirs.  Then we won't need any
 policy because there is no change in behavior without modifying the
 project to add at least one VERSION to a project() command.

I updated the topic on stage, it basically does that now.
I haven't updated the test yet.

Alex
-- 

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-14 Thread Alexander Neundorf
On Tuesday 14 January 2014, Matthew Woehlke wrote:
 On 2014-01-14 10:37, Brad King wrote:
  On 01/13/2014 01:38 PM, Alexander Neundorf wrote:
  does this require a policy now ?
  
  Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a
  project(Foo)
  call in a subdir, which would now unset Foo_VERSION_MAJOR.
  The same for PROJECT_VERSION_MAJOR, but this is maybe less likely.
  
  I don't think project(Foo) needs to affect Foo_VERSION_* when no
  VERSION argument is given (but should handle empty VERSION ).
  It should still handle PROJECT_VERSION_* to ensure consistency
  with PROJECT_NAME.  That may need a policy, but it will be tricky
  because we need to know if the value came from a previous project()
  call or a user set() in order to know when to trigger compatibility.
  
  Perhaps project(... VERSION ...) can set some cmMakefile variable
  internally that says the project knows about versions so it is okay
  project(Foo) calls to unset them in subdirs.  Then we won't need any
  policy because there is no change in behavior without modifying the
  project to add at least one VERSION to a project() command.
 
 While that sounds good for 99.9% of cases, what about the case of
 project A that includes project B, where B is not updated, but A decides
 to start using project(...VERSION...). Now if B was using
 PROJECT_VERSION internally, it is broken. (Note that I'm implying that B
 is e.g. a separate repository that may not be as easy to update/fix as
 A.)

You mean
CMakeLists.txt:

project(Foo VERSION 1.2.3)

...

add_subdir(B)

B/CMakeLists.txt:

set(PROJECT_VERSION 4.5.6)
project(Bar)


Indeed.
In that case, PROJECT_VERSION will be unset afterwards.

If it would be 

B/CMakeLists.txt:


project(Bar)
set(PROJECT_VERSION 4.5.6)

everything is fine.

Alex
-- 

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-13 Thread Alexander Neundorf
On Friday 10 January 2014, Alexander Neundorf wrote:
 On Friday 10 January 2014, Brad King wrote:
  On 01/06/2014 04:41 PM, Alexander Neundorf wrote:
   I modified write_basic_package_version_file() accordingly, so that you
   can now simply do
   
   project(Foo VERSION 1.2.3)
   
   ...
   
   write_basic_package_version_file(FooConfigVersion.cmake
   
COMPATIBILITY AnyNewerVersion)
   
   and this will use the version number from the project() call
   automatically (if no VERSION has been given explicitely).
  
  One problem left to address is what to do when a project() command is
  invoked in a subdirectory.  It will set PROJECT_NAME, PROJECT_SOURCE_DIR,
  and PROJECT_BINARY_DIR but it should also *unset* the PROJECT_VERSION_
  variables if no VERSION argument is provided.  Otherwise the version
  values will not be consistent with the project name.
 
 right, unsetting sounds good.


does this require a policy now ?

Somebody could set Foo_VERSION_MAJOR in the toplevel subdir, and have a 
project(Foo)
call in a subdir, which would now unset Foo_VERSION_MAJOR.
The same for PROJECT_VERSION_MAJOR, but this is maybe less likely.

Alex
-- 

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-10 Thread Alexander Neundorf
On Friday 10 January 2014, Matthew Woehlke wrote:
 On 2014-01-10 11:01, Jean-Christophe Fillion-Robin wrote:
  Would it make sense to have project(Foo VERSION 1.2.3) set the 
variables:
 ${PROJECT_NAME}_PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK)
  
  That way, the variable would remain even if project is called with
  VERSION in sub directory.
 
 How is that different? Do you mean to drop the PROJECT_VERSION_{...}
 entirely? That doesn't seem desirable for symmetry with the other
 PROJECT_{...} variables.
 
 I think I'm with Brad; set the PROJECT_VERSION_{...} and
 ${PROJECT_NAME}_VERSION_{...} (note; no extra literal 'PROJECT') as
 usual. Always. Whether or not VERSION was specified (i.e. unset the
 corresponding variables in such case).
 
 Folks that use the PROJECT_{...} forms hopefully know what they are
 doing, otherwise people are hopefully using the ${PROJECT_NAME}_{...}
 forms instead.
 
 
 Related: Do these affect the version properties of libraries? (Because
 OTOH if it does, I can imagine wanting to say VERSION once at the root
 and have it inherit downwards unless overridden. Maybe though that's a
 reason for it to not do so.)

I thought about that too.
Even without it, with the patch you now already have a standard form:

set_target_properties( PROPERTIES VERSIOn ${PROJECT_VERSION} )

Automatically doesn't really work, or at least it would have to be switched 
on:
set(CMAKE_USE_PROJECT_VERSION_FOR_LIBRARIES TRUE)
and then that property would automatically use ${PROJECT_VERSION}.

But that doesn't have to be done now, it can also be done later on.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-10 Thread Alexander Neundorf
On Friday 10 January 2014, Brad King wrote:
 On 01/06/2014 04:41 PM, Alexander Neundorf wrote:
  I modified write_basic_package_version_file() accordingly, so that you
  can now simply do
  
  project(Foo VERSION 1.2.3)
  
  ...
  
  write_basic_package_version_file(FooConfigVersion.cmake
  
   COMPATIBILITY AnyNewerVersion)
  
  and this will use the version number from the project() call
  automatically (if no VERSION has been given explicitely).
 
 One problem left to address is what to do when a project() command is
 invoked in a subdirectory.  It will set PROJECT_NAME, PROJECT_SOURCE_DIR,
 and PROJECT_BINARY_DIR but it should also *unset* the PROJECT_VERSION_
 variables if no VERSION argument is provided.  Otherwise the version
 values will not be consistent with the project name.

right, unsetting sounds good.

Should the full version 1.2.3 be put into PROJECT_VERSION or 
PROJECT_VERSION_STRING ?
Both forms are used in different places in cmake.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-10 Thread Alexander Neundorf
On Friday 10 January 2014, Alexander Neundorf wrote:
 On Friday 10 January 2014, Brad King wrote:
  On 01/06/2014 04:41 PM, Alexander Neundorf wrote:
   I modified write_basic_package_version_file() accordingly, so that you
   can now simply do
   
   project(Foo VERSION 1.2.3)
   
   ...
   
   write_basic_package_version_file(FooConfigVersion.cmake
   
COMPATIBILITY AnyNewerVersion)
   
   and this will use the version number from the project() call
   automatically (if no VERSION has been given explicitely).
  
  One problem left to address is what to do when a project() command is
  invoked in a subdirectory.  It will set PROJECT_NAME, PROJECT_SOURCE_DIR,
  and PROJECT_BINARY_DIR but it should also *unset* the PROJECT_VERSION_
  variables if no VERSION argument is provided.  Otherwise the version
  values will not be consistent with the project name.
 
 right, unsetting sounds good.

I added that to the AddVersionToProjectCommand branch on stage, along with a 
test.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] Generators and Extra Generators

2014-01-09 Thread Alexander Neundorf
On Wednesday 08 January 2014, Stephen Kelly wrote:
 Alexander Neundorf wrote:
  On Tuesday 07 January 2014, Stephen Kelly wrote:
  Is there a design issue here?
  
  I run cmake-gui and select the one I want from a list.
  What is the problem, the length of the list ?
 
 More the combinatorial expansion along multiple axes to add a new type
 indicates a 'design smell'.

this combinatorial expansion can be avoided, internally the main generator and 
the extra generator are kept separately, and the long list is basically only 
generated for presenting it to the user and letting him decide what he wants.
This could be presented simply in a different way.
As I said, in cmake-gui in some way split into two widgets, and for the CLI it 
could be split into -G maingenerator -X extragenerator.
This would need changes mainly in cmake::CreateGlobalGenerator() and 
cmake::AddExtraGenerator().

Then it goes down from more or less m*n to m+n.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] Generators and Extra Generators

2014-01-09 Thread Alexander Neundorf
On Tuesday 07 January 2014, Stephen Kelly wrote:
 David Cole wrote:
  There's been a design issue since extra generators were introduced...
  
  The question is: is it possible to resolve it with a better design and
  still keep the existing functionality?
 
 Hence this mail :), and my mail to cmake.users about the Kate Extra
 Generator being the wrong interface/design.
 
 I'd like to see cmake generate all the info a UI would need in a simple and
 non-tied-to-a-particular-implementation way. That would be something Qt
 Creator and Kate could use as it would list the targets, the compile lines
 for objects, link targets, link lines etc. 

Actually an IDE may have somewhat different needs.
As long as it uses an existing buildtool (make or ninja), it doesn't actually 
need the commands for linking, and also not necessarily for compiling. (if the 
IDE would execute e.g. the link commands directly instead of calling make 
foo, then the IDE would need to be a complete buildtool, i.e. with full 
dependency handling between the targets etc.).
It does need information which include dirs and definitions are used, per 
target, probably better per source file, so it can do proper completion etc.
IMO it needs information in which CMakeLists.txt a target has been added, to 
support the user by editing the cmake files.
It needs to know to which target(s) a source file belongs, and vice versa, it 
needs to know the language of each source file (since this can be overridden 
via the LANGUAGE property in cmake).
I'm quite sure IDE developers can think of more they'd like to know.

As I said, it would be really cool if this information could be put complete 
and IDE-independent in a project file. 

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] cmake --help-custom-modules compatibility

2014-01-09 Thread Alexander Neundorf
On Wednesday 08 January 2014, you wrote:
 On 11/20/2013 07:22 PM, Stephen Kelly wrote:
  The solution is still to re-implement the --help-custom-modules
  myman.1 command-line behavior as a special case with warnings.  Alex
  and Steve will have to work out who takes responsibility for that.
  
  I'll defer to Alex on doing that I think.
 
 Alex, Steve, we need to resolve this compatibility issue soon
 in preparation for the 3.0 release.  

since a few weeks I only sporadically find some time :-), so don't rely on me, 
I can't promise anything currently.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] Generators and Extra Generators

2014-01-07 Thread Alexander Neundorf
On Tuesday 07 January 2014, Stephen Kelly wrote:
 Hi,
 
 With the addition of the Kate Project stuff, we got 4 new generators rather
 than a single option to generate the information needed by Kate in a
 generator independent way, similar to CMAKE_EXPORT_COMPILE_COMMANDS.
 
  http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/48412/focu
 s=48471
 
 The addition of an Android Makefiles generator would also require
 
  Kate Project - Android Makefiles
  Eclipse - Android Makefiles
  CodeBlocks - Android Makefiles
  CodeLight - Android Makefiles
 
 etc.
 
 If android decides Ninja is a good idea someday, we get more dimensional
 expansion.
 
 Is there a design issue here?

I run cmake-gui and select the one I want from a list.
What is the problem, the length of the list ?
Then just split the GUI into two dependent comboboxes.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] Generators and Extra Generators

2014-01-07 Thread Alexander Neundorf
On Tuesday 07 January 2014, Stephen Kelly wrote:
 David Cole wrote:
  There's been a design issue since extra generators were introduced...
  
  The question is: is it possible to resolve it with a better design and
  still keep the existing functionality?
 
 Hence this mail :), and my mail to cmake.users about the Kate Extra
 Generator being the wrong interface/design.

Sorry about that.
But it does something useful for me, and for other users of the (existing) 
kate project plugin.
Since one of the core features of cmake is to create project files for IDEs, 
creating project files for kate doesn't look that wrong to me.

 I'd like to see cmake generate all the info a UI would need in a simple and
 non-tied-to-a-particular-implementation way. That would be something Qt
 Creator and 

That would be nice.
Once this format exists, IDE developers just need to make use of it.

 Kate could use as it would list the targets, the compile lines
 for objects, link targets, link lines etc. 

Just to avoid misunderstandings: there is currently nothing in kate which uses 
such information, and as far as I know nothing is planned.

Alex
--

Powered by www.kitware.com

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

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

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

Re: [cmake-developers] RFC: add version to project() call

2014-01-07 Thread Alexander Neundorf
On Monday 06 January 2014, Rolf Eike Beer wrote:
 Am Montag, 6. Januar 2014, 23:26:49 schrieb Alexander Neundorf:
  On Monday 06 January 2014, Rolf Eike Beer wrote:
   Am Montag, 6. Januar 2014, 22:41:26 schrieb Alexander Neundorf:
Hi,

on cmake stage I have a simple branch AddVersionToProjectCommand.
This extends the project command to also accept a version number:

project(Foo VERSION 1.2.3 CXX)
   
   Cool, I like this. Shouldn't there be spaces on both sides of operators
   (e.g. '= 2')?
   
   ?
 
 I mean in the C++ code where you check the components.

Ah, yes.

Alex
--

Powered by www.kitware.com

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

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

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


[cmake-developers] RFC: add version to project() call

2014-01-06 Thread Alexander Neundorf
Hi,

on cmake stage I have a simple branch AddVersionToProjectCommand.
This extends the project command to also accept a version number:

project(Foo VERSION 1.2.3 CXX)

All that does is setting some more variables (beside PROJECT_NAME, 
PROJECT_SOURCE_DIR, PROJECT_BINARY_DIR and the projectName_... equivalents).

When setting a version, you also get PROJECT_VERSION and 
PROJECT_VERSION_(MAJOR|MINOR|PATCH|TWEAK) variables as well as the 
projectName_... equivalents.

These version variables can then be used in other commands/macros/functions 
which need a version.
I modified write_basic_package_version_file() accordingly, so that you can now 
simply do

project(Foo VERSION 1.2.3)

...

write_basic_package_version_file(FooConfigVersion.cmake
 COMPATIBILITY AnyNewerVersion)

and this will use the version number from the project() call automatically (if 
no VERSION has been given explicitely).

Comments ?

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] RFC: add version to project() call

2014-01-06 Thread Alexander Neundorf
On Monday 06 January 2014, Rolf Eike Beer wrote:
 Am Montag, 6. Januar 2014, 22:41:26 schrieb Alexander Neundorf:
  Hi,
  
  on cmake stage I have a simple branch AddVersionToProjectCommand.
  This extends the project command to also accept a version number:
  
  project(Foo VERSION 1.2.3 CXX)
 
 Cool, I like this. Shouldn't there be spaces on both sides of operators
 (e.g. '= 2')?

 ?

This basically only sets up version variables for the current project, i.e. it 
replaces

project(Foo CXX)

set(Foo_VERSION_MAJOR 1)
set(Foo_VERSION_MINOR 2)
set(Foo_VERSION_PATCH 3)
set(Foo_VERSION
${Foo_VERSION_MAJOR}.${Foo_VERSION_MINOR}.${Foo_VERSION_PATCH})


with one function call, which results in a set of variables with standard 
names (not related to find_package()).

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] Request to review topic codelite-ide-generator

2014-01-05 Thread Alexander Neundorf
On Saturday 04 January 2014, Eran Ifrah wrote:
 Hi,
 
 I have added support for CodeLite IDE (topic name: codeite-ide-generator)
 If any of the developers can review it - it will be great
 
 P.S:
 This topic is related to this Mantis bug feature request:
 http://public.kitware.com/Bug/view.php?id=9901

I had a look last week and it looked good in general, and also seemed to work. 
:-)
Did you get around to add a test using codelite-make (or what the name was ) ?

Did you check whether everything works correctly if the source dir or the 
build dir contain spaces ?
e.g. $HOME/cmake/src dir/ and $HOME/cmake/build dir/ ?

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] Fwd: Supporting codelite IDE

2013-12-25 Thread Alexander Neundorf
Hi Eran,

On Wednesday 25 December 2013, Eran Ifrah wrote:
 Forwarding my email which I accidentally sent to the user's mailing list
 
 Thanks
 
 
 -- Forwarded message --
 From: Eran Ifrah eran.if...@gmail.com
 Date: Wed, Dec 25, 2013 at 2:02 PM
 Subject: Supporting codelite IDE
 To: cm...@cmake.org
 
 
 Hello,
 
 I got many requests over the years from many codelite users to support
 cmake.
 I saw that some work was done back in 2009 to support it but it was
 abandoned
 
 The original feature request is here:
 http://public.kitware.com/Bug/view.php?id=9901
 I have uploaded a patch file to the bug tracker based on the original work
 made by the original bug reporter
 
 I have test it locally on a huge project and it works perfectly
 
 Hope this patch will be applied

I saw your patch, it would be great if you could get it into cmake git :-)
...the author of an IDE personally works on the cmake generator for it... I 
think that's the best possible case :-)

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] cmake --help-custom-modules compatibility (was: RST and documentation)

2013-11-18 Thread Alexander Neundorf
On Monday 18 November 2013, Brad King wrote:
 On 11/18/2013 02:56 PM, Stephen Kelly wrote:
  We've had a while now to get used to the new docs system. Mostly I like
  it, though I haven't really looked much into what rst offers.
 
 This is really the start of several threads so I will branch out now.
 
  2) Compatibility
  KDE relied on --help-custom-modules for creating a man page of the kde
  cmake
  
  modules. That does not work with CMake 3.0.0:
   http://quickgit.kde.org/?p=kdelibs.gita=commitdiffh=804d35394c366
  
  I am left wondering why it would be difficult to process the existing
  (and very simple) markup in custom modules and generate rst on the fly
  for output from --help-module MyCustomModule and similar. Is there a
  reason not to restore compatibility like that? Otherwise any distro
  which upgrades to cmake 3 will lose those man pages in the KDE case, and
  probably similar in other cases.
  
  I think it would be best to avoid situations like distros packaging cmake
  2.8 and cmake 3.0, possibly renaming executables etc etc so that KDE4 and
  other packages can continue to rely on cmake 2.8. Restoring and keeping
  compatibility with issues like this would be important to prevent that.
 
 The conversion topic was massive as it was and I didn't want to handle
 this.  I didn't know it was used for anything except local command-line
 help convenience.  The old help infrastructure was certainly not ever
 intended for invocation in project build rules.

the author of the --help-custom-modules command line option certainly intended 
this to be used by other projects. ;-)
I don't know whether this is used only in KDE or also in other projects.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments

2013-11-08 Thread Alexander Neundorf
On Friday 08 November 2013, Daniele E. Domenichelli wrote:
 Hello,
 
 I updated the CMakeParseArguments_EmptyArgs topic, the new behaviour is
 now decided as follows:
 
 * If CMAKE_MINIMUM_REQUIRED_VERSION  2.8.13, the default behaviour is
   to skip empty arguments, otherwise the default behaviour is to keep
   them.
 * Using the CMAKE_PARSE_ARGUMENTS_DEFAULT_SKIP_EMPTY directory
   property the user can explicitly set the default behaviour for a
   folder and its subfolders.
 * Using CMAKE_PARSE_ARGUMENTS_(SKIP|KEEP)_EMPTY or as the first
   argument of the call after the mandatory ones, the user can specify
   whether to keep or to skip the empty arguments, regardless of the
   default behaviour for that cmake_parse_arguments() call.
 
 Therefore the new syntax is:
 
   cmake_parse_arguments(
 prefix
 options
 one_value_keywords
 multi_value_keywords
 [CMAKE_PARSE_ARGUMENTS_(SKIP|KEEP)_EMPTY]
 args...
 )
 
 Does it look better now?
 
 
 Unfortunately there still a big problem, that is probably in the c++
 source code, because set(var value PARENT_SCOPE) still fails if
 value is empty. This is a small example that shows the problem:
 
 ---
 
 function(_foo)
 set(FOO  PARENT_SCOPE)
 endfunction()
 
 foo(FOO foo)
 _foo()
 if(DEFINED FOO)
   message(FOO DEFINED)
 else()
   message(FOO NOT DEFINED)
 endif()
 
 set(BAR )
 if(DEFINED BAR)
   message(BAR DEFINED)
 else()
   message(BAR NOT DEFINED)
 endif()
 
 ---
 
 The output of this is:
 
 FOO NOT DEFINED
 BAR DEFINED
 
 So it looks like that set(FOO  PARENT_SCOPE) instead of setting an
 empty FOO value, unsets it in the parent scope, and the behaviour is
 definitely different from set for the current scope.
 
 This looks like a bug to me... How should I handle this?

the implementation in set() doesn't differentiate whether it was set to empty 
or whether there was no value at all.
In most cases it doesn't matter much whether a variable is empty or not 
defined, if it is dereferenced it gives an empty string in both cases, if() 
also interprets both as false.
It's more or less only if(DEFINED) which detects the difference, right ?

How about adding one new policy modify handling of empty variables which is 
used by both ?
Then you don't need the directory property and the extra argument.
Having two separate policies would be cleaner, but it seems a bit overkill to 
me, since most probably both changes won't break many, if any, builds.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments

2013-11-06 Thread Alexander Neundorf
On Wednesday 06 November 2013, Daniele E. Domenichelli wrote:
 On 05/11/13 20:51, Alexander Neundorf wrote:
  I don't know if this is to be considered a change of behaviour though,
  but I'd rather consider it a bug, and I would like to see it fixed in
  the next bugfix release... what do you think?
  
  cmake_parse_arguments() is used in quite a few places in the meantime, so
  I don't really feel good about changing its behaviour in general.
  Maybe an option for the macro what it should do with empty values ?
 
 Is there any of the other place where cmake_parse_arguments() has to
 deal with with empty arguments? 

We cannot know what users are doing with it.

 I believe that someone would have
 complained about that. From what I've seen, modules that are supposed to
 deal with empty arguments (like ExternalProject that can have arguments
 like INSTALL_COMMAND ) do not use CMakeParseArguments...
 
 I don't think that anyone would use something like
   SINGLE  VALUE
 to assign VALUE to the SINGLE option...
 Also something like
   SINGLE ${EMPTY_VARIABLE} NEXT_ARG
 would assign to FOO_SINGLE the value NEXT_ARG
 and that is very likely to be an unintended behaviour.
 
 Perhaps someone could use something like
   MULTI ${V1} ${EMPTY_VARIABLE} ${V2}
 and expect to get a list containing only V1 and V2. Nonetheless if he is
 using foreach(arg ${list}), the behaviour won't change because empty
 list elements are skipped. if instead he is using foreach(arg IN LIST
 list), he is probably expecting to receive empty arguments, since the
 documentation clearly states so.
 
 Adding an option in the macro arguments would be a bit of a
 non-compatible change, since the name of the option could no longer be
 used as one of the OPTION/SINGLE/MULTI value names.

This is all correct.
It seems unlikely that changing this will actually break something.
Adding an option like DONT_SKIP_EMPTY_ARGUMENTS, e.g at the second argument 
position, means that this keyword cannot be used as an option name by users 
anymore. By making the keyword longer or more detailled, this becomes less 
likely. E.g. I'd assume nobody is using CMAKE_DONT_SKIP_EMPTY_ARGUMENTS.

Adding proper named argument handling to cmake_parse_arguments() itself is 
somewhat complicated since it can't make use of cmake_parse_arguments() ;-)
 
The macro could check ${CMAKE_MINIMUM_REQUIRED_VERSION} whether 2.8.13/3.0.0 
is required, and switch behaviour based on that. Or via a policy. This would 
be the normal wy to handle such a change.
I'm not sure whether this wouldn't be a bit much for a change which most 
likely doesn't break anything anyway.

But... I've had my share of changes which seemed to be safe, and then somebody 
came along with a setup which was broken by this change nevertheless.

So, I'll have a slightly bad feeling if you commit it without additional 
checks. Probably it will be ok.
If you commit it with a policy, everything should be fine.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui

2013-11-05 Thread Alexander Neundorf
On Tuesday 05 November 2013, David Cole wrote:
  My question is still not answered completely:
  
  When should the new variable be added? On startup is not really
  possible because it might be the case that your src/binary directory
  is not set properly.
  
  So you would agree that it makes sense to do it on configure but
  only if the cache is empty? This will not allow to overwrite the
  variable via parameter but I guess that usecase is not very
  common?
  
  On startup is the only time it does make sense. After that, the user
  should be in charge, and the command line settings should not be
  re-applied again after a user makes an edit. You don't need the
  src/binary directories set properly necessarily in order to add a
 
 cache
 
  entry to the UI.
  
  ...
  
  - What should happen with a -D option if there is not initially a
 
 build
 
  directory selected?
 
 It should add UI entries even though there is no build directory
 selected, and set them according to the -D values. Then, the -D values
 should be forgotten about and never applied again during that session,
 regardless of future user actions.
 
 Also, you could require that for -D args to work properly, the current
 directory *is* the binary directory at startup time (just like cmake
 and ccmake). If you're passing -D arguments to the gui program, then
 you have control over its launching point, and can set the current
 directory to be whatever you like.
 
 If launched without a build directory, you could choose the last known
 build directory (if there is one) just like cmake-gui does now.
 
 If no build directory, no -D args.

I tried the following a few times in the past and noticed everytime that it 
does not work:
$ cd src
src/ $ mkdir build
src/ $ cd build
src/build/ $ cmake-gui -DSOME_VARIABLE=some_value ..

I'd like that to work. Would it work with your proposal ?

Once the cache is deleted in cmake-gui, I would expect that the values from 
the command line are also forgotten, also the -U values. Otherwise this cmake 
would remove the matching entries from every cache I load.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui

2013-11-05 Thread Alexander Neundorf
On Tuesday 05 November 2013, Jean-Christophe Fillion-Robin wrote:
 Would it makes sense to have cmake-gui behaving like ccmake ? After all
 there are both UI.
 
 It would accept the same set of options:
 
   -C initial-cache  = Pre-load a script to populate the cache.
   -D var:type=value = Create a cmake cache entry.
   -U globbing_expr  = Remove matching entries from CMake cache.

I agree.

   -G generator-name = Specify a makefile generator.
   -T toolset-name   = Specify toolset name if supported by
 generator.

Not sure about these two. I have to select them anyway when starting 
configure, I don't see much value in overriding this from the command line.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] CMakeParseArguments: Do not skip empty arguments

2013-11-05 Thread Alexander Neundorf
On Tuesday 05 November 2013, Daniele E. Domenichelli wrote:
 Hello all,
 
 Current implementation of cmake_parse_arguments skips empty arguments.
 
 For example:
 
   cmake_parse_arguments(OPTION SINGLE MULTI ${ARGN})
 
 with ARGN that is set using something like:
 
   args SINGLE  more args  # (args;SINGLE;;more args)
   args SINGLE   # (args;SINGLE;)
 
 it will fail in 3 different ways:
 
 1) because the foreach skips empty arguments
 2) because list(APPEND list ${currentArg}) will fail to append an
empty element to the list if currentArg is an empty string.
 3) because empty arguments are not passed to cmake_parse_arguments
if not quoted, i.e. if ARGN=a;;b
* ${ARGN} will pass the arguments a, b
* ${ARGN} will pass the arguments a, , b

Not sure about the third point. It could be done intentionally that way in 
order to ignore empty strings.
 
 I wrote a small patch to fix this, you can find it in the
 CMakeParseArguments_EmptyArgs topic. This patch fixes the first
 behaviour using foreach(IN LISTS) version, the second by enclosing
 currentArg in quotes where required, and finally fixes the documentation
 in order to suggest to use quoted  ${ARGN} in order not to miss the
 empty arguments at the end of the list.
 
 I don't know if this is to be considered a change of behaviour though,
 but I'd rather consider it a bug, and I would like to see it fixed in
 the next bugfix release... what do you think?

cmake_parse_arguments() is used in quite a few places in the meantime, so I 
don't really feel good about changing its behaviour in general.
Maybe an option for the macro what it should do with empty values ?

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] [CMake] Forwarding parameters to cmake through cmake-gui

2013-11-05 Thread Alexander Neundorf
On Tuesday 05 November 2013, Matthew Woehlke wrote:
 On 2013-11-05 14:36, Alexander Neundorf wrote:
  I tried the following a few times in the past and noticed everytime that
  it does not work:
  $ cd src
  src/ $ mkdir build
  src/ $ cd build
  src/build/ $ cmake-gui -DSOME_VARIABLE=some_value ..
  
  I'd like that to work. Would it work with your proposal ?
 
 Yes.
 
  Once the cache is deleted in cmake-gui, I would expect that the values
  from the command line are also forgotten, also the -U values. Otherwise
  this cmake would remove the matching entries from every cache I load.
 
 True. (But what if that's what you want?)

I think I would expect -U only to work if a cache is loaded initially, i.e. if 
cmake-gui is started with an existing build dir.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] Major.Minor version install directories

2013-10-25 Thread Alexander Neundorf
On Friday 25 October 2013, Stephen Kelly wrote:
 Brad King wrote:
...
  FYI, I keep my test install tree below my build directory
  
  and wipe it out before the next install:
   rm -rf $whatever_you_call_the_prefix
   make install
 
 That doesn't work for me because my qtbase prefix is where I install qtbase
 dev branch and other Qt repos (also dev branch), cmake (master, a topic or
 whatever version I need to test the Qt cmake files with), some KDE stuff
 and some KDAB stuff.

I have a directory full of different versions of cmake next to each other, 
prefix/cmake-2.4.5/ ... prefix/cmake-2.8.12/, and next to it 
prefix/cmake-HEAD/, so they are always cleanly separated and can be deleted 
without problems.
Just for cmake you don't need to set any prefixes, just calling the one I need 
with the full path has always worked for me.

Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] Review request: Qt-auto-generators

2013-10-24 Thread Alexander Neundorf
On Thursday 24 October 2013, Stephen Kelly wrote:
 Hi,
 
 I've pushed the Qt-auto-generators topic to stage. This topic was discussed
 here:
 
  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7936
 
 I have tested it with ports of KDE Frameworks and GammaRay to use the
 features.
 
 Alex, could you also review the topic please?

Looks good in general.
Just some nitpicking: this is still Qt-specific, so I would prefer to have 
something related to Qt in the names of the target properties and output and 
maybe also if the generated files instead of AUTOGEN_TARGETS_FOLDER, 
AUTOGEN: and  and AutogenInfo.cmake.

Alex

--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] FindPkgConfig and CMAKE_PREFIX_PATH

2013-10-22 Thread Alexander Neundorf
On Tuesday 22 October 2013, Daniele E. Domenichelli wrote:
 Hello all,
 
 FindPkgConfig does not support the CMAKE_PREFIX_PATH variable.
 This is because pkg-config uses the PKG_CONFIG_PATH and does not know
 anything
 about CMAKE_PREFIX_PATH.
 
 As a consequence, pkg-config packages built and installed in a non standard
 directory using ExternalProject, cannot be found, while cmake ones can
 be easily
 located setting the CMAKE_PREFIX_PATH variable.
 
 Do you think it could make sense to add to FindPkgConfig something like
 this?
 
   set(_pkgconfig_path $ENV{PKG_CONFIG_PATH})
   foreach(_dir ${CMAKE_PREFIX_PATH})
 set(ENV{PKG_CONFIG_PATH} $ENV{PKG_CONFIG_PATH}:${_dir}/lib/pkgconfig)
   endforeach()
 
   [...] (search for package)
 
   set(ENV{PKG_CONFIG_PATH} ${_pkgconfig_path})

good idea I think.
I guess it should also take lib64/ and the multiarch lib dirs into account.
You may have a look into GNUInstallDirs.cmake, there this is handled too.


Alex
--

Powered by www.kitware.com

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

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

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


Re: [cmake-developers] Fwd: CMake System Prefix Path

2013-10-22 Thread Alexander Neundorf
On Tuesday 22 October 2013, Alexander Neundorf wrote:
 On Tuesday 22 October 2013, Stephen Kelly wrote:
  Forwarding this for Ben.
  
  Would it be reasonable to have a way to not add the CMAKE_INSTALL_PREFIX
  to the CMAKE_SYSTEM_PREFIX_PATH?
  
  The install prefix is not cleared before the CI build on build.kde.org
  because the dependency graph is quite large (everything depends on Qt,
  most things depend on kdelibs, some things depend on kdepimlibs etc).
  
  Successful builds are uploaded to a master server and build nodes will
  re-download that if they have no version of the dependency. That
  re-download can be huge and take significant time, so it is avoided by
  also not clearing the install prefix on each of the build nodes.
  
  Is the only solution to this as Ben describes with
  passing NO_CMAKE_SYSTEM_PATH to CMake?
 
 Is everything installed into its own separate directory, or everything into
 one common install directory ?

Is still cmake git next used for the builds ?
It is only one line in UnixPaths.cmake, so a workaround for that special case 
could be to simply use a patched version of 2.8.12, which is the version 
required by kdelibs, and comment that one line out.

Alex
--

Powered by www.kitware.com

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

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

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


  1   2   3   4   5   6   7   >