Re: [CMake] Should header files be listed for a target?

[Alexander Neundorf]

On Mittwoch, 11. September 2019 21:22:04 CEST Kyle Edwards via CMake wrote:
> On Wed, 2019-09-11 at 22:00 +0300, Avraham Shukron wrote:
> > On Wed, Sep 11, 2019 at 9:49 PM Kyle Edwards  > 
> > m> wrote:
> > > You can list them or not list them. CMake will recognize them as
> > > header
> > > files and ignore them (not attempt to compile them.) It's a matter
> > > of
> > > personal preference. CMake's own CMake script lists them, but there
> > > are
> > > plenty of projects that don't and work just fine.
> > 
> > And it far as IDE generators (Xcode, CodeBlocks etc) go - don't they
> > care about headers?
> 
> Yes, the headers are more important for IDE generators than they are
> for Make/Ninja (though, AFAIK, they still don't affect the build, just
> the files that the developer sees in the generated project in the IDE.)

it depends.
If you use e.g. the kate project generator, and your project is in svn or git, 
kate retrieves the full list of files via svn/git.
Some generators check whether there is a foo.h in the same directory if there 
is a foo.cpp listed, and add this automatically.

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

Re: [CMake] Install without building unittests

[Alexander Neundorf]

On 2019 M03 28, Thu 18:22:03 CET Scott Bloom wrote:
> Just a note, for google later on… 
> 
> The default appears to have the variable unset, so it doesn’t show up in the
> list of variables in ccmake or the cmake-gui.
 
> I also added it to my system before any INSTALL command was called.  I don’t
> know if that is necessary, but it does work
 
> SET( CMAKE_SKIP_INSTALL_ALL_DEPENDENCY TRUE )

I'm not sure how that applies to the MSVC generators, but when using 
Makefiles, you can do
make install/fast
which just installs without 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:
https://cmake.org/mailman/listinfo/cmake

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

[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

[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] link only with targets feature

[Alexander Neundorf]

On 2019 M02 12, Tue 08:02:43 CET Starka Tomáš wrote:
> tldr;
> It would be wonderful to have function or signature for
> target_link_libraries tha would link only to a targets. Did I overlook
> something?
> 
> like target_link_libraries(name [PUBLIC...] TARGETS myFavouriteLib ...
> QUIET/VERBOSE)
> 
...
> But then I guess it wouldn't hurt to have something like
> target_link_libraries(name [PUBLIC...] TARGETS myFavouriteLib ...
> QUIET/VERBOSE) which would not try to give linker myFavouriteLib.lib
> if there was no target of that name in question. Or
> target_link_targets... realy doesn't matter as long as it does that
> and maybe when asked by the last parameter it gives an error if the
> one of the target is non-existent or ill-formed. 

I agree to target_link_targets().
Additionally I would prefer if (maybe with a policy) include directories would 
be only applied when using target_link_targets(), but not when using 
target_link_libraries().
This would make it more obvious IMO.

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

Re: [CMake] List all packages

[Alexander Neundorf]

On 2019 M01 13, Sun 09:43:03 CET Lectem wrote:
> Hi,
> 
> Is there a way to list all the packages (both config files and find-modules)
> that find_package could find ? Could we even imagine this would also permit
> to list the variables and targets created in it ? I think that would be a
> very helpful to have for debugging find_package, especially when you don’t
> have access to the system having issues (user bug reports for example).

you may have a look at FeatureSummary.cmake, maybe this is 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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Removing RPATH from existing binaries

[Alexander Neundorf]

On 2019 M01 5, Sat 08:06:31 CET Federico Milano wrote:
> Hi. When packaging my application, I'm using install (FILES...) to copy
> some third party executables to my binary folder.
> 
> 1. I do not know if I'm doing it right or if I should use install
> (PROGRAMS...)
> 2. Some of the binaries have a RPATH, and I want to remove it. Is there any
> CMake macro/function to do that, or should I call directly chrpath?

if you look at the generated cmake_install.cmake scripts, you'll see the calls 
cmake uses to modify the RPATH when installing, I think it's some undocumented 
subfunction of the file() command.

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

Re: [cmake-developers] CMake Cache Library

[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] Default library name?

[Alexander Neundorf]

On 2018 M11 5, Mon 13:20:32 CET Robert Maynard wrote:
> Yes, you can do that.  I don't know if there is an easier way than the
> following:

you could have a look at the following variables:
CMAKE_STATIC_LIBRARY_PREFIX
CMAKE_STATIC_LIBRARY_SUFFIX
CMAKE_SHARED_LIBRARY_PREFIX
CMAKE_SHARED_LIBRARY_SUFFIX
CMAKE_EXECUTABLE_SUFFIX

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

Re: [CMake] Removing rpath paths

[Alexander Neundorf]

On 2018 M10 28, Sun 18:46:24 CET you wrote:
> El 28/10/18 a las 18:32, Alexander Neundorf escribió:
> > well, then you do have some RPATH/RUNPATH somewhere ;-). As you say
> > probably in the libraries.
> > ld.so.conf could also contains additional search directories, but I doubt
> > that that's the case for you.
> 
> Yes, I found two libraries with rpath in them.  I used the commandline:
> 
> chrpath -d library
> 
> to remove it.  Now all is fine with the world.

Ok.
Then actually you shouldn't need any RPATH settings.
The default by cmake is that you get the full RPATH in the build tree and an 
empty RPATH in the install 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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Removing rpath paths

[Alexander Neundorf]

On 2018 M10 28, Sun 14:20:40 CET you wrote:
> El 28/10/18 a las 13:59, Alexander Neundorf escribió:
> > On 2018 M10 28, Sun 10:19:58 CET Gonzalo Garramuño wrote:
> > ...
> > 
> >> 3) Why does running 'readelf -d myexecutable | grep RPATH' returns
> >> nothing
> > 
> > only grep for "PATH", then you also get the newer RUNPATH entry.
> > 
> > Alex
> 
> Thanks.  I tried it but it also shows nothing.  In principle I don't
> have any rpath.  However, in behavior I do.

well, then you do have some RPATH/RUNPATH somewhere ;-). As you say probably 
in the libraries.
ld.so.conf could also contains additional search directories, but I doubt that 
that's the case for you.

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

Re: [CMake] Removing rpath paths

[Alexander Neundorf]

On 2018 M10 28, Sun 10:19:58 CET Gonzalo Garramuño wrote:
...
> 3) Why does running 'readelf -d myexecutable | grep RPATH' returns nothing

only grep for "PATH", then you also get the newer RUNPATH entry.

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

Re: [CMake] protobuf and imports relative to root (and --proto_path)

[Alexander Neundorf]

On 2018 M09 25, Tue 16:53:27 CEST David Jobet wrote:
> > What I do have a problem is rerunning protoc automatically on proto-files
> > which import proto files that have been modified.
> > How do you handle this ?
> 
> I just found out I don't.
> Any idea on that one ?

here are some suggestions:
https://cmake.org/pipermail/cmake-developers/2018-May/030664.html

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

Re: [CMake] protobuf and imports relative to root (and --proto_path)

[Alexander Neundorf]

On 2018 M08 23, Thu 12:50:14 CEST David Jobet wrote:
> Hello,
> 
> I'm trying to port an existing project from premake to cmake.
> I'm trying to avoid modifying the source files while doing so.
> 
> Right now, we have several libraries (read in different directories) using
> proto files with imports between them.
> All imports are made relative to the root of the project.
> 
> e.g :
> work/lib1/sublib1/a.proto
> work/lib1/sublib1/b.proto
> 
> with a.proto having a link to b.proto like this "import
> lib1/sublib1/b.proto"
> 
> If I compile this with an unchanged FindProtobuf.cmake, I do this :
> 
> protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS a.proto b.proto)
> add_library(...)
> 
> the problem being that it looks like the "namespaces" generated by protoc
> in b.proto do not match the one used in a.proto : it does not compile.

do you mean protoc fails, or that the C++ compiler fails when compiling the 
generated file ?
I'm also using proto files with imports between them and don't have problems 
with finding them.
Are you setting the PROTOBUF_IMPORT_DIRS variable ?

What I do have a problem is rerunning protoc automatically on proto-files which 
import proto files that have been modified.
How do you handle this ?

> Is there a way to make this work ?
> 
> Otherwise, I made the patch below which solves my problem. Do you think it
> could be included in cmake ?
> it defines a new option PROTO_PATH, so the decl above becomes
> protobuf_generate_cpp(PROTO_SRCS PROTO_HRDS PROTO_PATH ${CMAKE_SOURCE_DIR}
> a.proto b.proto)
> 
> With regards
> 
> David
> 
> $ diff share/cmake-3.10/Modules/FindProtobuf.cmake.orig
> share/cmake-3.10/Modules/FindProtobuf.cmake

can you please use diff -bup ?
This makes the patch easier to read.

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

Re: [CMake] How to build fully correctly versioned shared object files with cmake

[Alexander Neundorf]

On 2018 M08 6, Mon 21:54:33 CEST Hendrik Sattler wrote:
> Am 6. August 2018 20:27:23 MESZ schrieb Philip Van Hoof 
:
> >Hello everyone,
> >
> >I noticed that it sometimes happens that I find a package for a shared
> >object file(s) (or DLLs, on platforms like Windows) that have a build
> >set up using cmake, that doesn't set everything that should be set.
> >
> >Usually as packagers of various popular open source softwares correct
> >enthusiasts' attempts at understanding the sometimes bizarre
> >complexities of for example autotools, but (although it's all less
> >complicated) also cmake, it ends up somewhat right. Somewhat. I noticed
> >that especially in corporate world, things tend to go spectacularly
> >wrong. Almost without exception.
> >
> >In particular am I concerned about ABI versioning of shared object
> >files so that they are easy to package and distribute by various
> >operating systems (like, among others, Linux distributions). But also
> >API versioning of development files (compiler header files and pkg-
> >config) and installing to the right installation paths.
> >
> >I wanted to invite the community to scrutinize some equivalent examples
> >that I made for autotools (with libtool), qmake, cmake and meson.
> >
> >https://github.com/pvanhoof/dir-examples/
> >
> >In particular I wanted to invite the cmake community to take a look at
> >this example:
> >
> >https://github.com/pvanhoof/dir-examples/tree/master/cmake-example
> >
> >The idea is that the examples are as correct as possible. That means
> >the examples should simple and educational. Easing (some amount) of
> >platform independence (ie. supporting Windows) and packaging.
> 
> Is there ANY reason to use libtool library versioning? It might surprise
> people but it really is not any kind of standard.
> 
> Just change the SOVERSION when you make incompatible ABI changes and a
> normal library VERSION. There's really not more to it, especially nothing
> like the sick results that libtool produces, sometimes.

I agree.
I would recommend
Major version  = SO version, increase it if you break ABI compatibility
Minor version: increase it if you add ABI compatible features
Patch version: increase it for bug fix releases.

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

Re: [CMake] simple find_package example

[Alexander Neundorf]

On 2018 M08 2, Thu 10:01:39 CEST Randy Heiland wrote:
> Hi,
> 
> I'd like to figure out how to modify the simple "hello" demo (
> https://cmake.org/examples/) so that the Hello project is a library with an
> accompanying FindHello.cmake and then the Demo project uses that
> information and "find_package" to discover/use it.
> 
> Hopefully that makes sense. Basically, I'm looking for a simple tutorial on
> how I can make my library easily accessible to a CMake project. 

for that, you don't want a FindHello.cmake (which would typically be shipped 
either by cmake or by the consuming application), instead you want to generate 
and install a HelloConfig.cmake file.

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

Re: [CMake] Using Different Computers for cmake and ctest

[Alexander Neundorf]

On 2018 M07 18, Wed 09:49:47 CEST Brian S wrote:
> I currently use cmake/ctest to build and test my software. The software is
> C++/CUDA. During the build step I don't need a GPU but in the test step I
> do. I would like to build the code with cmake on a cluster with many CPUs
> and then run the tests using ctest on a target machine with a GPU. Is this
> possible?

as far as I know this is currently not possible.
I would also like to do that, to test the same executable on a set of 
different clusters (or at least with a different number of nodes. For that 
there is no need to rebuild the project multiple times.

For tests, cmake generates CTestTestFile.cmake. 
These are executed when running a test.
Copying the buildtree somewhere and then see what happens when you run ctest. 
E.g. RPATHs probably won't be correct. The tests may also have references into 
the source directory.

Having a nice way to do this properly would be nice IMO :-)

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

Re: [CMake] Eclipse CDT4 - Unix Makefiles / Ninja Generator

[Alexander Neundorf]

On 2018 M07 7, Sat 19:09:18 CEST Martin Weber wrote:
> Hi all,
> 
> FYI, according to this [1], those generators do no longer work with the new
> core build introduced in CDT 9.5.
> 
> Martin
> 
> [1] http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg33066.html

do you know whether the new build system of CDT is documented somewhere ?
I found this, but this is far from enough.
http://www.eclipse.org/org/langsymp/CDT%20Managed%20Build%20System.pdf

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

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

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

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

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

[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

[CMake] How to handle dependencies of protobuf files ?

[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

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

[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] How to build CMake so it works on an older Linux?

[Alexander Neundorf]

On 2018 M04 5, Thu 15:15:21 CEST Juan E. Sanchez wrote:
> The example I just sent was for building in centos 6, because 5 is gone.

not really gone, it's still in vault.centos.org :-)
https://hub.docker.com/r/aneundorf/centos5-build-base/~/dockerfile/

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

Re: [CMake] How to build CMake so it works on an older Linux?

[Alexander Neundorf]

On 2018 M04 5, Thu 12:50:04 CEST Ben Sferrazza wrote:
> 
> Were you able to actually build the newer versions of Cmake that require
> c++11 on Centos 5? 

I didn't try 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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] How to build CMake so it works on an older Linux?

[Alexander Neundorf]

On 2018 M04 5, Thu 21:24:40 CEST Alexander Neundorf wrote:
> On 2018 M04 5, Thu 16:15:17 CEST suzuki toshiya wrote:
> > Dear Eric,
> > 
> > # if anybody think "how C++11 environment should be prepared
> > # on legacy GNU/Linux" is off-topic and should be discussed
> > # in off-list, please let me know. I will do so.
> > 
> > Eric Wing wrote:
> > > Thanks for the responses. Yes, I just need this to run on Ubuntu 12.04
> > > (and some other old Linux's in that era). Yes, I think the probably is
> > > the libstdc++ dependency.
> > > 
> > > As pointed out, it is really hard to get a newer compiler on Ubuntu
> > > 12.04. I've been down this road before, and if memory serves, the gcc
> > > bootstrapping process to get a newer compiler doesn't seem to work
> > > with a compiler older than gcc 4.8. Same goes for clang, which also
> > > weirdly relies on gcc 4.8 to bootstrap itself.
> > 
> > At least, gcc-4.6.3, the last official gcc for Ubuntu-12.04, could
> > build gcc-4.8.5 manually (without shared libstdc++, so confused
> > dependency could be avoided). And, I could build cmake-3.11.0 by it.
> > Now I'm checking "make test".
> 
> I have recently built a gcc 4.9.5 on Centos 5, i.e. gcc 4.1. There were no
> issues after getting the configure flags right.

4.9.4 I mean.
You can see the flags here:
https://hub.docker.com/r/aneundorf/docker-centos5-build-svn-gcc/~/dockerfile/
(but the docker image didn't build, it was killed by a dockerhub timeout).

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

Re: [CMake] How to build CMake so it works on an older Linux?

[Alexander Neundorf]

On 2018 M04 5, Thu 16:15:17 CEST suzuki toshiya wrote:
> Dear Eric,
> 
> # if anybody think "how C++11 environment should be prepared
> # on legacy GNU/Linux" is off-topic and should be discussed
> # in off-list, please let me know. I will do so.
> 
> Eric Wing wrote:
> > Thanks for the responses. Yes, I just need this to run on Ubuntu 12.04
> > (and some other old Linux's in that era). Yes, I think the probably is
> > the libstdc++ dependency.
> > 
> > As pointed out, it is really hard to get a newer compiler on Ubuntu
> > 12.04. I've been down this road before, and if memory serves, the gcc
> > bootstrapping process to get a newer compiler doesn't seem to work
> > with a compiler older than gcc 4.8. Same goes for clang, which also
> > weirdly relies on gcc 4.8 to bootstrap itself.
> 
> At least, gcc-4.6.3, the last official gcc for Ubuntu-12.04, could
> build gcc-4.8.5 manually (without shared libstdc++, so confused
> dependency could be avoided). And, I could build cmake-3.11.0 by it.
> Now I'm checking "make test".

I have recently built a gcc 4.9.5 on Centos 5, i.e. gcc 4.1. There were no 
issues after getting the configure flags right.

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

Re: [CMake] cmake --find-package deprecated?

[Alexander Neundorf]

On 2018 M04 3, Tue 16:01:58 CEST jeandet wrote:
> Hi all,
> 
> Reading the documentation I can see:
> https://cmake.org/cmake/help/v3.11/manual/cmake.1.html?highlight=find%2
> 0package#find-package-tool-mode id="-x-evo-selection-start-marker">
> "
> Note
> 
> This mode is not well-supported due to some technical limitations. It
> is kept for compatibility but should not be used in new projects.
> "
> 
> Does this means that:
>   1) We will always support this but it's limited.
>   2) We will be supported for a long time, but you shouldn't use it.
>   3) We plan to remove this soon, don't use this!

I think it's in 2).
 
> In fact this mode would really be useful outside of CMake, to use
> libraries/stuff which doesn't provide pc files but only CMake packages.
> Even if this has limitations, it's better than nothing.

Yes, that was my motivation a few years back.
There is even a cmake.m4 which adds a cmake_find_package macro for configure.

Since then, there was close to no feedback.
I also can't remember any volunteer contributions for this feature.
Currently it has more limitations than it had 7 or 8 years ago or so.

The idea was to run cmake in script mode, and basically just execute the 
requested FindFoo.cmake script, which basically searches a set of directories 
and returns the results.
With imported targets, their link interfaces and e.g. generator expressions 
things got more complicated.

I'd be happy if somebody picks up the work and makes this feature work 
properly.

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

Re: [CMake] [proposal] Support for modern CMake

[Alexander Neundorf]

On 2018 M03 20, Tue 21:14:30 CET Mateusz Loskot wrote:
...
> Why I can not write:
> 
> target_use(app Boost::system Boost::filesystem)
> 
> or
> 
> target_use_targets(app Boost::system Boost::filesystem)
> 
> and, actually read and understand what I'm doing?
> 
> (If you're now typing "why don't you create a custom macro wrapper"
> response, please don't!)
> 
> How nicely it would fit into the concept of CMake member functions
> presented by Daniel [1] (@17:25 min), wouldn't it?
> 
> 
> Disclaimer: Originally, the idea came from Colby Pike [2] who suggested [3]
> use_targets(app Boost::system)

Not sure, I guess I was earlier ;-)
You may want to have a look at 
https://cmake.org/pipermail/cmake-developers/2012-December/017561.html
and the following discussion.

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

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

[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

[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

[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

[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] [cmake] [RFC] rewriting FindMKL

[Alexander Neundorf]

On 2018 M01 22, Mon 15:16:50 CET Sik wrote:
> Hello CMake users and devs,
> 
> In openmeeg we are reviewing our MKL package finder to make it more
> maintainable for ourselves and others who had adopted our solution.
> Therefore I'm writing you requesting comments and feedback so that is
> useful for everyone.
> 
> Here is the project we have set up in order to test it. It has a simple
> example using MKL and CI for different scenarios.
> 
> https://github.com/openmeeg/findmkl_cmake

that's quite a lot of stuff, I'll try to test itin the next days.

Just a few quick comments:

The MESSAGE() in line 39 is ALL_UPPERCASE.

MKL_ROOT_DIR from line 31 is put into the cache, reusing the same variable 
name in line 35 probably works, but the interaction between cache- and non-
cache variables is somewhat complicated, so I would recommend to use different 
names.

When searching mkl_cblas.h in line 31, in case the Intel compiler is used, the 
install directory of CMAKE_CXX_COMPILER could be used in some way as a hint to 
help finding MKL.

I don't like the error message in line 39, I usually prefer using 
CMAKE_PREFIX_PATH.

Lines 87 to 95 are not correctly indented, also lines 105 to 112.

Is BLA_STATIC in line 117 correct, or is this a typo ?

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

Re: [cmake-developers] kwsysProcess threadsafety

[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] RPATH for pkg-config

[Alexander Neundorf]

On 2018 M01 4, Thu 10:06:26 CET Franck Houssen wrote:
...
> ...
> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> foreach(lib ${PETSc_LDFLAGS})
>   target_link_libraries(main PUBLIC ${lib})
>   message("target_link_libraries - lib is ${lib}")
> endforeach(lib)
> 
> foreach(dir ${PETSc_LIBRARY_DIRS})
>   link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
>   message("link_directories - dir is ${dir}")
> endforeach(dir)
> 
> This gives:
> >> cmake ..; make
> 
> ...
> target_link_libraries - lib is -L/path/to/petsc/local/lib
> target_link_libraries - lib is -lpetsc
> link_directories - dir is /path/to/petsc/local/lib

yes, so cmake doesn't know that it will link to /path/to/petsc/local/lib/
libpetsc.so .
I usually recommend to use the results from pkgconfig as input to 
find_library() 
etc. calls, ie. put the directory reported by pkgconfig in the HINTS section of 
find_library(). This should then return the full path to the library, which you 
can then use in target_link_libraries(), and cmake will take care of the 
rpath.

...
> >> ldd main
> 
>   linux-vdso.so.1 (0x7ffebab8a000)
>   libmpi_cxx.so.20 => /usr/lib/x86_64-linux-gnu/libmpi_cxx.so.20
> (0x7f36172e3000) libmpi.so.20 => /usr/lib/x86_64-linux-gnu/libmpi.so.20
> (0x7f3616fed000) libpetsc.so.3.8 => not found


you can also use readelf or objdump to see the RPATH entry in the ELF file 
directly.

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

Re: [CMake] coding style for modules

[Alexander Neundorf]

On 2018 M01 4, Thu 05:09:54 CET Dave Milter wrote:
> Hello,
> 
> If there is some libfoo that I want to use in my project,
> and this libfoo has it's own CMakeLists.txt I have 3 options to deal
> with such external dependency:
> 
> a) Treat it like every other external dependency and write cmake code
>   like FindLibFoo.cmake to find libfoo on file system.

This would be a clean solution if you don't want to build libfoo as part of 
your project.

> b)Include this project as git submodule and use ExternalProject to
> invoke `cmake` and `cmake --build`

This would be a clean solution if you want to build libfoo as part of yur 
project.

> 
> c)Include this project as git submodule and use add_subdirectory(libfoo)

the "parent" project will/can influence the behaviour of libfoo then, I would 
not recommend this.

Or use d) as Alan suggests.

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

Re: [CMake] RPATH for pkg-config

[Alexander Neundorf]

On 2018 M01 3, Wed 10:08:09 CET Franck Houssen wrote:
> Hello,
> 
> How to ask cmake to add a library path (coming from pc file) to rpath ?
> 
> I checked this https://cmake.org/Wiki/CMake_RPATH_handling, but still not
> working. Can somebody help ?
> >> more main.cpp
> 
> #include 
> 
> int main(int argc, char ** argv) {
> PetscInitialize(, , NULL, "");
> PetscFinalize();
> return 0;
> }
> 
> >> more CMakeLists.txt
> 
> cmake_minimum_required(VERSION 3.7)
> enable_language(CXX)
> 
> find_package(MPI REQUIRED)
> find_package(PkgConfig REQUIRED) # Get pkg_check_modules.
> pkg_check_modules(PETSc REQUIRED PETSc)
> 
> project(main)
> add_executable(main main.cpp)
> 
> target_include_directories(main PUBLIC ${MPI_CXX_INCLUDE_PATH})
> target_link_libraries(main PUBLIC ${MPI_CXX_LIBRARIES})
> 
> target_include_directories(main PUBLIC ${PETSc_INCLUDE_DIRS})
> foreach(lib ${PETSc_LDFLAGS})
> target_link_libraries(main PUBLIC ${lib})
> endforeach(lib)

How does each ${lib} look like ?
Is it "-lpetsc" or does it have the full path to the libraries ?
You should use the full path to the libraries, otherwise cmake doesn't know 
where they are and the RPATH computation will not work.

> 
> foreach(dir ${PETSc_LIBRARY_DIRS})
> link_directories(main PUBLIC ${dir}) # Not sure: is this needed ?
> endforeach(dir)

no, link_directories() in general should not be used.

> # use, i.e. don't skip the full RPATH for the build tree
> SET(CMAKE_SKIP_BUILD_RPATH FALSE)
> # when building, don't use the install RPATH already
> # (but later on when installing)
> SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
> SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")

If the automatic computation fails, you could add the petsc lib dir here as 
INSTALL_RPATH

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

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

[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

[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

[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] Feature request: change how CMake chooses compiler when Ninja is used (Windows)

[Alexander Neundorf]

On 2017 M05 27, Sat 15:49:35 CEST biologi spm wrote:
> Hi CMake developers,
> 
> When both Mingw64 GCC and MSVC is available in PATH and run cmake
> -GNinja, cmake always choose GCC. I have to manually remove GCC from
> PATH or type -DCMAKE_IGNORE_PATH= which is very long.

you can set the CC and CXX env. variables to point at the compiler you want to 
use. CMake should pick this one up then.

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

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

[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] cdash/ctest question

[Alexander Neundorf]

Hi John,

On 2016 M01 19, Tue 07:55:27 CET Biddiscombe, John A. wrote:
> Alex
> 
> Thank you for this information. I shall test this out right away.

so, did it work out ?

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

Re: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

[Alexander Neundorf]

On 2017 M02 3, Fri 20:32:58 CET you wrote:
> FWIW, we've moved to CentOS 6 for the binaries we package and distribute
> for ParaView.  It's about the oldest widely deployed Linux distro that's
> still actively supported (EL5 is EOL'd and most deployments have long since
> moved to 6 or 7).  

Yes, most, but not all ;-)

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

Re: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

[Alexander Neundorf]

On 2017 M02 2, Thu 20:07:29 CET you wrote:
> Hi Gonzalo,
> 
> Using the dockcross/manylinux-x64 docker image should allow to build you
> project out-of-the-box.
> It is based on Centos5, include recent gcc, CMake, Git, etc ...
> 
> See https://github.com/dockcross/dockcross
> 
> In a nutshell,
> 
> # Pull image
> docker pull dockcross/manylinux-x64
> 
> # Generate helper script
> docker run --rm dockcross/manylinux-x64 > dockcross-manylinux-x64
> chmod +x ./dockcross-manylinux-x64
> mv ./dockcross-manylinux-x64 ~/bin/
> 
> # Build your project
> cd /path/to/src
> dockcross cmake -Bbuild -H. -GNinja
> 
> 
> The directory build will then contain the build tree of your project
> compiled using gcc provided by the Centos5 image and link against an old
> glibc.

when docker starts, you are usually root in the container, and if then 
something is built, the files belong to root, and not the user as which you are 
logged in.
How do you handle that ?
I just found a hackish way (a shell script which sets up a user with the same 
numerical ID) to have the same user ID in the container as on the host system. 
Is there a better way ?

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

Re: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

[Alexander Neundorf]

On 2017 M01 26, Thu 18:23:05 CET Gonzalo Garramuño wrote:
> I currently own an Ubuntu Xenial 14.04.1 LTS box in which I do all my
> work.I distribute a binary image viewer.   However, recently one of
> my users tried to run the viewer on a CentOS 7 distro and found out that
> that distro libc and libstdc++ are older and incompatible.
> 
> I would like to compile my program targeting the older libc and
> libstdc++.  Those files come with symbol version and visibility. Is
> there an easy way to do that other than copying the old libraries?

you may consider using docker to provide a build environment for an "old" 
distribution (CentOS 7 is actually quite bleeding edge... ;-) )
There are some CentOS5 images on dockerhub.

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

Re: [cmake-developers] Eclipse CDT Managed build

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

[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] Function declaration scope

[Alexander Neundorf]

On 2016 M11 29, Tue 14:42:49 CET Robert Bielik wrote:
> Hmm.. using v3.7 the answer is no, i.e. a function declared in a subfolder
> will be available in parent scope. Seems a bit odd, doesn't it ?

this has been discussed here just recently...

Functions and macros are global.
Once they are defined, they are available everywhere, also in parent 
directories 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

Re: [CMake] Adding Cmake version in online documentation

[Alexander Neundorf]

On Wednesday 09 November 2016 09:22:24 Nils Gladitz wrote:
...
> You said you are not forcing your users to upgrade by setting a policy
> to OLD.
> Which implied that not setting the policy to OLD would force your users
> to upgrade ... which it doesn't.
> 
> >> In fact all that setting it to OLD does is suppress the warning.
> > 
> > It's better than emitting zillion of warnings to the output, right?
> > You can suppress one type and fix another, set TODOs, etc.
> 
> Policy warnings are intended to encourage you to switch to new
> behaviours since the old ones are deprecated.
> In actively maintained projects they are not meant to be suppressed.


I heard that argumentation several times, and still don't agree.

"actively maintained" doesn't automatically mean to always require the newest 
versions of everything, see the mail from Albrecht Schlosser (FLTK) or how 
CMake requirements were handled during the KDE4 era.

To make the software buildable on as many as possible systems, it helps to not 
to require new versions of any needed tools or libraries.

So, Albrecht can absolutely actively maintain FLTK, and at the same time 
decide to require a relatively old cmake version (Ok, 2.6 is ancient).

As long as he doesn't plan to update the required version for cmake, I would 
suppress all policy warnings about new behaviour.
Is it guaranteed that changing the code so that the warning, which appeared 
e.g. in cmake 3.4, is fixed, still works correctly with the old, required 
version of cmake ?
I think no.

Once there is a plan to upgrade the cmake version, the warnings become useful, 
but IMO not before.

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

Re: [CMake] Adding Cmake version in online documentation

[Alexander Neundorf]

On Wednesday 09 November 2016 00:47:39 Albrecht Schlosser wrote:
> On 08.11.2016 23:01 Nils Gladitz wrote:
> > On 08.11.2016 20:26, Albrecht Schlosser wrote:
> >> I'm a developer of a public GUI library (FLTK). In this position you
> >> don't know anything about the availability of CMake versions on your
> >> target platforms. Our intention is to keep cmake_minimum_required() as
> >> low as possible.
> > 
> > If you are intending to keep the required version as low as possible
> > you'll already have a justification / reason for doing so.
> > I can only assume that the reason is that you need to support ancient
> > platforms which ship equally ancient versions of CMake and you don't
> > want to bother your users to build or install custom newer versions of
> > CMake.
> > 
> > It doesn't matter what your reasons or justifications for it are (though
> > I would hope they are valid and verified) but you have to decide on a
> > minimum version that you can life with in the end.
> 
> Basically that's a floating target. We need to evaluate this from time
> to time and maybe adjust the required version.

You could have a look at the major distributions and what they ship.
The oldest I have to support is RHEL 5, released first 2007, and that feels 
really ancient. But there are people out there which still run such systems.
Centos 5 comes with CMake 2.6.4, Centos 6 with 2.8.12.
OTOH, installing additional versions of CMake is really easy, thanks to the 
binary packages provided by Kitware (... which IIRC are built in a Docker 
Centos 5 container).

Btw. I really appreciate your idea to keep the requirements low. :-)
 
> >> That said, whenever you change a CMakeLists.txt file you should be
> >> aware if the commands you use are compatible with the CMake version
> >> you "require". There should be an easy way to find out in which
> >> version a particular CMake command has been introduced. Only with this
> >> information you can decide if you should use this fine command or
> >> better find another way to do the task you're going to do.
> > 
> > At this point you only have to refer to the documentation that actually
> > corresponds to the version you decided to require.
> > You'll only find commands and behaviours in that documentation that'll
> > actually be available in your minimum version.
> 
> Yep, that's simple, of course. But if there is a (new) command you want
> to use it would be interesting to know the CMake version it was
> introduced to _decide_ if you can or want to do without it or raise the
> required version. I'm sure that we will raise the required version when
> CMake gets (or got) a new feature we need to use. But we need the facts
> to decide...

You can have a look here, there is the documentation for all cmake versions 
back to 2.6: https://cmake.org/documentation/

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

Re: [CMake] Splitting in multiple directories

[Alexander Neundorf]

On Tuesday 12 July 2016 09:00:43 portolan wrote:
> Hello,
> 
> I am new to Cmake and I have a pretty strange behaviour: I set my c+++
> project to work with a single CMakefile.txt, and now I am trying to have
> a more proper version with a .txt for each subdirectory
> 
> Pretty normal stuff, my source tree is:
> 
>  --Lib(my sources)
> 
>   --Logger   (as the name says, a logger)
> 
>  --Lib_UT  (Unitary tests for CxxTest)
> 
>  --Lib_UT_Runner  (the Cxx-generated test runner)
> 
> 
> I have a Lib_UT/CMakefile.txt and Lib_UT_Runner/CMakefile.txt, I call
> them using include_directory(Lib_UT) and


I guess you mean add_subdirectory() ?


> include_directory(Lib_UT_Runner) and everything is fine (apart from the
> runner executable being in a different directory)
> 
> BUT is I do the same for the logger, Lib_UT_Runner has a linking error
> where it cannot link to LibLogger.so. But the shared library is
> correctly generated and it is on the command line :
> 
> /usr/bin/c++  -lpthread CMakeFiles/Lib_UT_Runner.dir/Runner.cpp.o
> -o Lib_UT_Runner ../Lib_UT/libLib_UT.so ../libLib.so ../libLogger.so
> -lpthread
> -Wl,-rpath,/home/michele/mast-devel/cmake_debug/Lib_UT:/home/michele/mast-de
> vel/cmake_debug:/home/michele/mast-devel/cmake_debug/Logger
> 
> I tried using find_library, but I always get not-found


what's the error message ?

Posting relevant bits of your CMakeLists.txt (related to subdirs, creating 
targets and linking) would be helpful too.

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

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

[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] How to check if Eclipse CDT4 generated project is set up correctly?

[Alexander Neundorf]

On Monday, April 18, 2016 16:57:52 Nils Rathmann wrote:
> Hi,
> when I setup with the Eclipse CDT4 generator, as described here:
> https://cmake.org/Wiki/Eclipse_CDT4_Generator4
> 
> my [Targets] folder contains virtual folders for CMakeRules, Header
> Files, Object Files, Resources and Source Files, 

Yes, those are the standard groups created by cmake.

> but only the source files folder is filled. 

If you list also the header files in the sources for a target, they will 
appear in the [Header Files] group.

> The other folders are always empty, even if I
> build the target or the whole project. Is there a documentation where I
> can see how a generated Eclipse project should look like? When I compare
> my project with the sample screenshot in the wiki linked above, it looks
> totally different (mine has a lot of virtual folders like Subprojects,
> Targets, ...)

you should have a [Source directory] virtual folder pointing to 
${CMAKE_SOURCE_DIR}.
You should have a virtual folder [Subprojects], with one subdir for every 
project()-call in your project.

The "Make targets" tab should have some global targets to  build (like all, 
clean, rebuild_cache) and a "Build" and "Clean" make target for every target.

Is this so ?

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

[Cmake-commits] CMake branch, next, updated. v3.5.2-969-g69b7868

[Alexander Neundorf]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  69b7868da554b594849d5c3d89839ee54d659cd8 (commit)
   via  6e3259705146a62693eef1a7617ebabcc9ac4fa6 (commit)
   via  6f139d31cad75a25c1421b84d5d034cc72081205 (commit)
   via  94179ecf22a819e3f9ae32c9e865c483202b9818 (commit)
  from  2a0451e7f129aa27b824741cb7db3a9e3706b1a7 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=69b7868da554b594849d5c3d89839ee54d659cd8
commit 69b7868da554b594849d5c3d89839ee54d659cd8
Merge: 2a0451e 6e32597
Author: Alexander Neundorf <neund...@kde.org>
AuthorDate: Sun Apr 17 15:41:37 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Sun Apr 17 15:41:37 2016 -0400

Merge topic 'AddDocumentationForEclipseVariables' into next

6e325970 Add documentation for Eclipse-generator related variables. #15827
6f139d31 CMake Nightly Date Stamp
94179ecf CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6e3259705146a62693eef1a7617ebabcc9ac4fa6
commit 6e3259705146a62693eef1a7617ebabcc9ac4fa6
Author: Alex Neundorf <neund...@kde.org>
AuthorDate: Sun Apr 17 21:38:45 2016 +0200
Commit: Alex Neundorf <neund...@kde.org>
CommitDate: Sun Apr 17 21:38:45 2016 +0200

Add documentation for Eclipse-generator related variables. #15827

diff --git a/Help/manual/cmake-variables.7.rst 
b/Help/manual/cmake-variables.7.rst
index 7cf3a3d..3e04763 100644
--- a/Help/manual/cmake-variables.7.rst
+++ b/Help/manual/cmake-variables.7.rst
@@ -116,6 +116,10 @@ Variables that Change Behavior
/variable/CMAKE_DEBUG_TARGET_PROPERTIES
/variable/CMAKE_DEPENDS_IN_PROJECT_ONLY
/variable/CMAKE_DISABLE_FIND_PACKAGE_PackageName
+   /variable/CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES
+   /variable/CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT
+   /variable/CMAKE_ECLIPSE_MAKE_ARGUMENTS
+   /variable/CMAKE_ECLIPSE_VERSION
/variable/CMAKE_ERROR_DEPRECATED
/variable/CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
/variable/CMAKE_EXPORT_COMPILE_COMMANDS
diff --git a/Help/variable/CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES.rst 
b/Help/variable/CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES.rst
new file mode 100644
index 000..331aae8
--- /dev/null
+++ b/Help/variable/CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES.rst
@@ -0,0 +1,10 @@
+CMAKE_ECLIPSE_GENERATE_LINKED_RESOURCES
+---
+
+This cache variable is used by the Eclipse project generator.  See
+:manual:`cmake-generators(7)`.
+
+The Eclipse project generator generates so-called linked resources
+e.g. to the subproject root dirs in the source tree or to the source files
+of targets.
+This can be disabled by setting this variable to FALSE.
diff --git a/Help/variable/CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT.rst 
b/Help/variable/CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT.rst
new file mode 100644
index 000..7b4367d
--- /dev/null
+++ b/Help/variable/CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT.rst
@@ -0,0 +1,11 @@
+CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT
+-
+
+This cache variable is used by the Eclipse project generator.  See
+:manual:`cmake-generators(7)`.
+
+If this variable is set to TRUE, the Eclipse project generator will generate
+an Eclipse project in :variable:`CMAKE_SOURCE_DIR` . This project can then
+be used in Eclipse e.g. for the version control functionality.
+:variable:`CMAKE_ECLIPSE_GENERATE_SOURCE_PROJECT` defaults to FALSE; so
+nothing is written into the source directory.
diff --git a/Help/variable/CMAKE_ECLIPSE_MAKE_ARGUMENTS.rst 
b/Help/variable/CMAKE_ECLIPSE_MAKE_ARGUMENTS.rst
new file mode 100644
index 000..6e8a408
--- /dev/null
+++ b/Help/variable/CMAKE_ECLIPSE_MAKE_ARGUMENTS.rst
@@ -0,0 +1,9 @@
+CMAKE_ECLIPSE_MAKE_ARGUMENTS
+
+
+This cache variable is used by the Eclipse project generator.  See
+:manual:`cmake-generators(7)`.
+
+This variable holds arguments which are used when Eclipse invokes the make
+tool. By default it is initialized to hold flags to enable parallel builds
+(using -j typically).
diff --git a/Help/variable/CMAKE_ECLIPSE_VERSION.rst 
b/Help/variable/CMAKE_ECLIPSE_VERSION.rst
new file mode 100644
index 000..8cc7882
--- /dev/null
+++ b/Help/variable/CMAKE_ECLIPSE_VERSION.rst
@@ -0,0 +1,10 @@
+CMAKE_ECLIPSE_VERSION
+-
+
+This cache variable is used by the Eclipse project generator.  See
+:manual:`cmake-generators(7)`.
+
+When using the Eclipse project generator, CMake tries to find the Eclipse
+executable and detect the version of it. Depending on the version it

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc3-280-g892a534

[Alexander Neundorf]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  892a53437ff2f626fdc19b568dd80eeb7a0a81a5 (commit)
   via  aff38945d64fc56026255c9cc3c1051529887d7b (commit)
   via  6ee6b17ed538989e38efb2eafb7f92c557eca71a (commit)
  from  fda5171148f691addee7d8c735c906d5eb086591 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=892a53437ff2f626fdc19b568dd80eeb7a0a81a5
commit 892a53437ff2f626fdc19b568dd80eeb7a0a81a5
Merge: fda5171 aff3894
Author: Alexander Neundorf <neund...@kde.org>
AuthorDate: Wed Feb 24 17:10:37 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Wed Feb 24 17:10:37 2016 -0500

Merge topic 'AddNewEclipseVersions' into next

aff38945 Eclipse: only add C/CXX macros if the language is enabled
6ee6b17e Eclipse: add newer version numbers


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=aff38945d64fc56026255c9cc3c1051529887d7b
commit aff38945d64fc56026255c9cc3c1051529887d7b
Author: Alex Neundorf <neund...@kde.org>
AuthorDate: Wed Feb 24 22:13:04 2016 +0100
Commit: Alex Neundorf <neund...@kde.org>
CommitDate: Wed Feb 24 22:13:04 2016 +0100

Eclipse: only add C/CXX macros if the language is enabled

With this patch, the builtin macros and include dirs are only
added to the project file if the C/CXX langauges are really enabled.
I.e. before this patch the CXX-stuff was in the project file as soon
as CXX had been enabled at least once for this build tree.
I.e. disabling CXX later on did not remove the CXX macros etc.
from the project file (related to #15150)

Alex

diff --git a/Source/cmExtraEclipseCDT4Generator.cxx 
b/Source/cmExtraEclipseCDT4Generator.cxx
index aedf6f4..133a85a 100644
--- a/Source/cmExtraEclipseCDT4Generator.cxx
+++ b/Source/cmExtraEclipseCDT4Generator.cxx
@@ -42,6 +42,8 @@ cmExtraEclipseCDT4Generator
   this->GenerateLinkedResources = true;
   this->SupportsGmakeErrorParser = true;
   this->SupportsMachO64Parser = true;
+  this->CEnabled = false;
+  this->CXXEnabled = false;
 }
 
 //
@@ -64,10 +66,12 @@ void cmExtraEclipseCDT4Generator
   {
   this->Natures.insert("org.eclipse.cdt.core.ccnature");
   this->Natures.insert("org.eclipse.cdt.core.cnature");
+  this->CXXEnabled = true;
   }
 else if (*lit == "C")
   {
   this->Natures.insert("org.eclipse.cdt.core.cnature");
+  this->CEnabled = true;
   }
 else if (*lit == "Java")
   {
@@ -890,7 +894,7 @@ void cmExtraEclipseCDT4Generator::CreateCProjectFile() const
   // add system defined c macros
   const char* cDefs=mf->GetDefinition(
   "CMAKE_EXTRA_GENERATOR_C_SYSTEM_DEFINED_MACROS");
-  if(cDefs)
+  if(this->CEnabled && cDefs)
 {
 // Expand the list.
 std::vector defs;
@@ -925,7 +929,7 @@ void cmExtraEclipseCDT4Generator::CreateCProjectFile() const
   // add system defined c++ macros
   const char* cxxDefs = mf->GetDefinition(
 "CMAKE_EXTRA_GENERATOR_CXX_SYSTEM_DEFINED_MACROS");
-  if(cxxDefs)
+  if(this->CXXEnabled && cxxDefs)
 {
 // Expand the list.
 std::vector defs;
@@ -979,7 +983,7 @@ void cmExtraEclipseCDT4Generator::CreateCProjectFile() const
   // CMakeSystemSpecificInformation.cmake. This makes Eclipse find the
   // standard headers.
   std::string compiler = mf->GetSafeDefinition("CMAKE_C_COMPILER");
-  if (!compiler.empty())
+  if (this->CEnabled && !compiler.empty())
 {
 std::string systemIncludeDirs = mf->GetSafeDefinition(
 "CMAKE_EXTRA_GENERATOR_C_SYSTEM_INCLUDE_DIRS");
@@ -988,7 +992,7 @@ void cmExtraEclipseCDT4Generator::CreateCProjectFile() const
 this->AppendIncludeDirectories(fout, dirs, emmited);
 }
   compiler = mf->GetSafeDefinition("CMAKE_CXX_COMPILER");
-  if (!compiler.empty())
+  if (this->CXXEnabled && !compiler.empty())
 {
 std::string systemIncludeDirs = mf->GetSafeDefinition(
   "CMAKE_EXTRA_GENERATOR_CXX_SYSTEM_INCLUDE_DIRS");
diff --git a/Source/cmExtraEclipseCDT4Generator.h 
b/Source/cmExtraEclipseCDT4Generator.h
index 16675f2..1da2077 100644
--- a/Source/cmExtraEclipseCDT4Generator.h
+++ b/Source/cmExtraEclipseCDT4Generator.h
@@ -116,6 +116,8 @@ private:
   b

Re: [CMake] Code::blocks: parallel build from IDE

[Alexander Neundorf]

On Sunday, January 17, 2016 14:01:59 Alexander Neundorf wrote:
> On Sunday, January 17, 2016 13:45:34 Dimitri Kaparis wrote:
> > On Sat, Jan 9, 2016 at 9:16 PM, Alexander Neundorf
> > <a.neundorf-w...@gmx.net>> 
> > wrote:
> > > On Saturday, January 09, 2016 12:27:48 Dimitri Kaparis wrote:
> > > > Greetings,
> > > > 
> > > > I'm using the "CodeBlocks - Unix Makefiles" generator under linux to
> > > 
> > > create
> > > 
> > > > a build tree for my project consisting of multiple executables and
> > > > libraries.
> > > > From the command line, I could use make -jN switch from the root of
> > > > the
> > > > build tree to invoke a full build in parallel, but I see no way of
> > > > doing
> > > > that from the Code Blocks IDE.
> > > 
> > > Oops, sorry, that's not implemented for C::B.
> > > 
> > > Alex
> > 
> > Any plans on it,
> 
> yes, but not commited yet.

it's in next now.
CMake now tries to figure out the number of CPUs, and sets the (new) cache 
variable CMAKE_CODEBLOCKS_MAKE_ARGUMENTS to "-jN".
If you don't like the result, you can set it to something else.

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

[Cmake-commits] CMake branch, next, updated. v3.5.0-rc3-248-g4cbf56e

[Alexander Neundorf]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  4cbf56e98c7c3ad3365350bd7ef9314263bb8862 (commit)
   via  84ccd4f7461ac2c2ee471a4d77f3e184c676c276 (commit)
  from  564c9c7b888fdfb156ed5b71de6172a032720c81 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4cbf56e98c7c3ad3365350bd7ef9314263bb8862
commit 4cbf56e98c7c3ad3365350bd7ef9314263bb8862
Merge: 564c9c7 84ccd4f
Author: Alexander Neundorf <neund...@kde.org>
AuthorDate: Tue Feb 23 16:45:28 2016 -0500
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Feb 23 16:45:28 2016 -0500

Merge topic 'CodeBlocksParallelFlag' into next

84ccd4f7 CodeBlocks: generate parallel project files (make -j)


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=84ccd4f7461ac2c2ee471a4d77f3e184c676c276
commit 84ccd4f7461ac2c2ee471a4d77f3e184c676c276
Author: Alex Neundorf <neund...@kde.org>
AuthorDate: Tue Feb 23 22:37:44 2016 +0100
Commit: Alex Neundorf <neund...@kde.org>
CommitDate: Tue Feb 23 22:37:44 2016 +0100

CodeBlocks: generate parallel project files (make -j)

This is done the same way as for Eclipse: cmake tries to determine
the number of CPUs, and then adds the respective -jN to the make
invocations in the project file.

Alex

diff --git a/Modules/CMakeFindCodeBlocks.cmake 
b/Modules/CMakeFindCodeBlocks.cmake
index f8d8d59..bf85ea0 100644
--- a/Modules/CMakeFindCodeBlocks.cmake
+++ b/Modules/CMakeFindCodeBlocks.cmake
@@ -23,3 +23,18 @@ endif()
 
 # Determine builtin macros and include dirs:
 
include(${CMAKE_CURRENT_LIST_DIR}/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake)
+
+# Try to find out how many CPUs we have and set the -j argument for make 
accordingly
+set(_CMAKE_CODEBLOCKS_INITIAL_MAKE_ARGS "")
+
+include(ProcessorCount)
+processorcount(_CMAKE_CODEBLOCKS_PROCESSOR_COUNT)
+
+# Only set -j if we are under UNIX and if the make-tool used actually has 
"make" in the name
+# (we may also get here in the future e.g. for ninja)
+if("${_CMAKE_CODEBLOCKS_PROCESSOR_COUNT}" GREATER 1  AND  CMAKE_HOST_UNIX  AND 
 "${CMAKE_MAKE_PROGRAM}" MATCHES make)
+  set(_CMAKE_CODEBLOCKS_INITIAL_MAKE_ARGS 
"-j${_CMAKE_CODEBLOCKS_PROCESSOR_COUNT}")
+endif()
+
+# This variable is used by the CodeBlocks generator and appended to the make 
invocation commands.
+set(CMAKE_CODEBLOCKS_MAKE_ARGUMENTS "${_CMAKE_CODEBLOCKS_INITIAL_MAKE_ARGS}" 
CACHE STRING "Additional command line arguments when CodeBlocks invokes make. 
Enter e.g. -j to get parallel builds")
diff --git a/Source/cmExtraCodeBlocksGenerator.cxx 
b/Source/cmExtraCodeBlocksGenerator.cxx
index 9348ef2..19f99ba 100644
--- a/Source/cmExtraCodeBlocksGenerator.cxx
+++ b/Source/cmExtraCodeBlocksGenerator.cxx
@@ -300,6 +300,8 @@ void cmExtraCodeBlocksGenerator
   // figure out the compiler
   std::string compiler = this->GetCBCompilerId(mf);
   std::string make = mf->GetRequiredDefinition("CMAKE_MAKE_PROGRAM");
+  const std::string makeArgs = mf->GetSafeDefinition(
+"CMAKE_CODEBLOCKS_MAKE_ARGUMENTS");
 
   fout<<"\n"
 "\n"
@@ -311,7 +313,8 @@ void cmExtraCodeBlocksGenerator
 "  "<<virtualFolders<<"\n"
 "  \n";
 
-  this->AppendTarget(fout, "all", 0, make.c_str(), lgs[0], compiler.c_str());
+  this->AppendTarget(fout, "all", 0, make.c_str(), lgs[0], compiler.c_str(),
+ makeArgs);
 
   // add all executable and library targets and some of the GLOBAL
   // and UTILITY targets
@@ -333,7 +336,8 @@ void cmExtraCodeBlocksGenerator
  (*lg)->GetBinaryDirectory())==0)
 {
 this->AppendTarget(fout, targetName, 0,
-   make.c_str(), *lg, compiler.c_str());
+   make.c_str(), *lg, compiler.c_str(),
+   makeArgs);
 }
   }
   break;
@@ -350,7 +354,7 @@ void cmExtraCodeBlocksGenerator
 }
 
   this->AppendTarget(fout, targetName, 0,
- make.c_str(), *lg, compiler.c_str());
+ make.c_str(), *lg, compiler.c_str(),makeArgs);
   break;
 case cmState::EXECUTABLE:
 case cmState::STATIC_LIBRARY:
@@ -360,11 +364,11 @@ void cmExtraCodeBlocksGenerator
   {
   cmGeneratorTa

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

[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

[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

[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] Incorporating cmake dir into configure.ac, but it depends on a autconf-managed in-tree library

[Alexander Neundorf]

On Thursday, February 11, 2016 13:11:29 Ron wrote:
> Hi,
> 
> I am working on a project that requires libevent and libevhtp.
> The latter is cmake managed, my project and libevent are autoconf managed.
> 
> (Note that libevhtp depends on libevent, both depend on openssl, which I
> rely
> on the system to provide.)
> 
> The problem is that I run cmake during the configure step, but during that
> time libevent has not been built yet, so libevhtp complains about not
> finding
> the libevent library.
> 
> I have to use in-tree libevent and libevhtp due to features I need, and
> libevhtp
> not being distributed by the linux distro I use.
> 
> What is the best way to approach this?

you should have a look how libevhtp searches for libevent.
If it does a bunch of find_library()/find_path() calls, those set cmake cacge 
variables, but only if they are not set yet.
So if you know where libevent will put its stuff, you can preset those cmake 
cache variables (e.g. using cmake -D ...)

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

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

[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] Finding Packages Installed in Non-Standard Locations

[Alexander Neundorf]

On Wednesday, February 03, 2016 13:08:42 Andrew Bell wrote:
> If my package is installed to a non-standard location, my
> Config.cmake file is currently also installed to the non-standard
> location and can't be found by dependent projects.
> 
> I see that there's export(PACKAGE ), but this creates an entry in
> the registry for the build location of the PROJECT rather than the
> installed location.
> 
> Is there some way I can install target files to a non-standard location but
> be sure that Config.cmake can be found without explicitly
> installing it into something like /usr/lib/cmake/PROJECT?

you can set the CMAKE_PREFIX_PATH environment 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

Re: [CMake] Code::blocks: parallel build from IDE

[Alexander Neundorf]

On Sunday, January 17, 2016 13:45:34 Dimitri Kaparis wrote:
> On Sat, Jan 9, 2016 at 9:16 PM, Alexander Neundorf <a.neundorf-w...@gmx.net>
> wrote:
> > On Saturday, January 09, 2016 12:27:48 Dimitri Kaparis wrote:
> > > Greetings,
> > > 
> > > I'm using the "CodeBlocks - Unix Makefiles" generator under linux to
> > 
> > create
> > 
> > > a build tree for my project consisting of multiple executables and
> > > libraries.
> > > From the command line, I could use make -jN switch from the root of the
> > > build tree to invoke a full build in parallel, but I see no way of doing
> > > that from the Code Blocks IDE.
> > 
> > Oops, sorry, that's not implemented for C::B.
> > 
> > Alex
> 
> Any plans on it, 

yes, but not commited yet.

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

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

[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] cdash/ctest question

[Alexander Neundorf]

On Thursday, January 14, 2016 21:51:23 Biddiscombe, John A. wrote:
> Apologies for posting a cdash question question to the cmake list…
> 
> CDash plots the run-time of tests, which is very useful indeed, but it would
> be even more useful if one could output a performance related ‘time’ from a
> test where a specific feature was being benchmarked and one could see how
> it changes over a period of days/weeks/months as changes to code are being
> made.
> The time would be specific to the tested code and not include
> startup and other uninteresting overheads (such as when the filesystem is
> misbehaving and the test starts slowly). 
> Does such a feature exist in ctest/cdash at all?

yes, we do exactly that.

You have to generate  tags in the stdoutof the test
42
1.23456

and then in cdash you can configure the tests-overview page to display certain 
such measurements by name, and on the tests page you can also display graphs 
for such named measurements.

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

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

[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

[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

[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

[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

[Alexander Neundorf]

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

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

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

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

Alex

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Code::blocks: parallel build from IDE

[Alexander Neundorf]

On Saturday, January 09, 2016 12:27:48 Dimitri Kaparis wrote:
> Greetings,
> 
> I'm using the "CodeBlocks - Unix Makefiles" generator under linux to create
> a build tree for my project consisting of multiple executables and
> libraries.
> From the command line, I could use make -jN switch from the root of the
> build tree to invoke a full build in parallel, but I see no way of doing
> that from the Code Blocks IDE.

Oops, sorry, that's not implemented for C::B.

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

Re: [CMake] Creating relocatable export files

[Alexander Neundorf]

On Saturday, November 14, 2015 12:19:11 Nicholas Braden wrote:
> Instead of using FOO_INCLUDE_DIR, I believe you should use
> target_include_directories() with the INTERFACE or PUBLIC options -
> this will export the include directories properly and they will be
> used when someone target_link_library()s your exported target.
> https://cmake.org/cmake/help/latest/command/target_include_directories.html?
> highlight=INTERFACE
> 
> There seems to be a section in the documentation on making sure your
> packages are relocatable:
> https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-re
> locatable-packages
> 
> See also:
> https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html

this is from before the fancy target-include-directories-propagation 
functionality was added, it shouldn't be necessary anymore.

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

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

[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

[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

[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

[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

[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

[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] Making CMake *not* use -isystem at all

[Alexander Neundorf]

On Monday, December 07, 2015 15:39:40 Attila Krasznahorkay wrote:
> Dear All,
> 
> I'm still debugging the performance problems of our build. But now I 
bumped
> into another surprising thing.
> 
> Our "highest level" packages can depend on a *lot* of low level 
packages.
> The one I'm testing now depends on more than 180 of them.
> 
> This generates >180 -isystem flags for the compilation lines. But I 
found a
> very surprising thing. If I replace all of these -isystem flags with -I
> ones by simply modifying the flags.cmake files that CMake generated 
for me,
> the build time of my code is cut to less than half of what it is when 
using
> -isystem.
> 
> So... How do I tell CMake to forget about using -isystem all together, 
and
> take all my include directories with -I?
> 
> Not using SYSTEM in target_include_directories and 
include_directories
> doesn't seem to make a difference. I still get all my out-of-source
> directories with -isystem. I even tried setting
> CMAKE_INCLUDE_SYSTEM_FLAG_CXX and 
CMAKE_INCLUDE_SYSTEM_FLAG_C to "-I "
> forcefully. But this didn't help either. Neither did explicitly unsetting
> these variables.

I would have expected this to work.
Maybe set them to -I on the initial cmake run ?

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

Re: [CMake] Best way to handle application data path for local run vs. installation

[Alexander Neundorf]

On Thursday, December 03, 2015 09:27:29 Ruslan Baratov via CMake 
wrote:

> On 03-Dec-15 04:34, Alexander Neundorf wrote:
> > On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote:

> > If RPATH was _designed_ to be patchable, tools could just do it,
> > instead of having to implement workarounds for longer strings. E.g.
> > the linker would support a command line argument how much 
space it
> > should reserve for the RPATH entry, or something like that.
> 
> I think it's not possible. As far as I know there is no limitation for
> path size on Linux for example. Hence it's not possible to predict what
> size for path to library user want to use by setting RPATH.

More nitpicking about the meaning of "designed" ;-) :

CMake knows the length of the build RPATH and the length of the install 
RPATH. Let's say the build RPATH has a length of 100, and the install 
RPATH has a length of 150, it could, during linking, give the build RPATH 
to the linker, and also something like --rpath-size=150, and the linker 
would make the field for the RPATH 150 bytes big, so it could be 
patched easly later on.
This is what I would consider the minimum support if it was "designed" 
to be patched.
Instead cmake has to add 50 ":" at the end of the build RPATH. :-/

...
> > The idea above was only for solving the question "am I installed ?"
> > yes/no, not "where am I installed ?".
> 
> Then I don't understand how it's planned to be used. I thought that in
> build directory you changing "_I_M_NOT_INSTALLED_" to
> "/path/to/build/directory" so resources can be found there, and on
> install you change it to "/path/to/install/directory". So my guess is
> not correct?


Nothing is planned, just some ideas.
The idea was, during install, to set the first byte of that special string to 
'\0', and in the code you test whether the string is empty ( -> it has been 
patched, so it is installed) or not (still the original 
"_I_M_NOT_INSTALLED_").

With that information, the developer can then do whatever he wants. e.g. 
when not installed, search just in $CMAKE_BINARY_DIR (which could 
be configured into some other string), and if installed, search in some 
other way.

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

Re: [CMake] Best way to handle application data path for local run vs. installation

[Alexander Neundorf]

On Wednesday, December 02, 2015 12:27:42 Ruslan Baratov wrote:
> On 02-Dec-15 05:13, Alexander Neundorf wrote:
...
> > well, the RPATH entry was not designed to be patched,
> 
> RPATH designed to be patched. And since it's a third time I'm making
> this statement please provide any arguments if you don't agree.
> 
> Here is mine (comes from wikipedia, 
https://en.wikipedia.org/wiki/Rpath):
> 
>  The rpath of an executable or shared library is an optional entry
> in the
>  .dynamic section of the ELF executable or shared libraries, with
> the type
>  DT_RPATH, called the DT_RPATH attribute. It can be stored there at
> link time by
>  the linker. Tools such as chrpath and patchelf can create or MODIFY
> the entry
>  later.
> 
> Man chrpath (http://linux.die.net/man/1/chrpath):
> 
>  -r  | --replace 
>  Replace current rpath or runpath setting with the path given


It doesn't matter and it is nitpicking: the RPATH entry has some size, and 
its content cannot simply be changed. I.e. it could be replaced with a 
string of the same length or a shorter one, but not a longer one.
CMake works around this by extending the build RPATH artificially with 
":" at the end I think, patchelf works around this by making the whole 
executable one page bigger if the new entry is longer.
If RPATH was _designed_ to be patchable, tools could just do it, instead 
of having to implement workarounds for longer strings. E.g. the linker 
would support a command line argument how much space it should 
reserve for the RPATH entry, or something like that.

> > any other string in an executable could be patched too:
> RPATH and C++ string literals have not the same nature. E.g. on my 
Linux
> machine RPATH string goes to ".dynstr" section and C++ literal to
> ".rodata" section.
> The difference is quite huge. By parsing ELF headers you can figure 
out
> RPATH offset and be 100% sure that patching is totally correct and
> doesn't affect other binary or general executable logic. RPATH is just a
> hint for linker.
> Changing bytes in .rodata is much trickier. E.g. how do you distinguish
> two strings:
> 
> void print_some_info() {
>const char* path = "/usr/local"; // must not be changed
>std::cout << "General note: user specific packages usually installed
> to " << path << std::endl;
> }
> 
> void parse_resources() {
>const char* resources_path = "/usr/local"; // want to change it in 
future
> std::string myresource = resources_path + "/foo/some.file";
> }
> 
> What if compiler merge them?


By using a very special string which is very unlikely to be used by 
something else, like e.g. "$$$_CMAKE_I_AM_NOT_INSTALLED_$$$".
Maybe it could even be put into a custom ELF section, and then tools 
could just look at that section (... but then it's ELF-only).

I would actually (despite it being hacky) trust the uniqueness of a string 
like the one above.
Probably the string could be made even more unique by embedding the 
target name or something using cmake functionality.

> (Just a general note, not related to how you want to implement 
resources
> trick)
> 
> > const char* my_builddir_flag = "_I_M_NOT_INSTALLED_";
> > 
> > ...
> > 
> > if (*my_builddir_flag)
> > 
> > {
> > 
> > ... code when not installed
> > 
> > }
> > 
> > else
> > 
> > {
> > 
> > ... code for the installed version
> > 
> > }
> > 
> > Just search for that string in the executable and replace the first
> > byte with a '\0'.
> 
> Still can violates logic. What if I want to print string to resources in
> next format:
> 1. "-" x size of path to resources (compiler can figure out it at
> compile time!)
> 2. path to resources
> 3. "-" x size of path to resources
> 
> If you pass "/usr/local" output will be (nice):
> 
> --
> /usr/local
> --
> 
> If you pass "/home/username", output will be (nice):
> 
> 
> /home/username
> 
> 
> If you pass "_I_M_NOT_INSTALLED_" then change string to
> "/usr/local" after install (ugly, not what I expect!):
> 
> ---
> /usr/local
> ---

Sorry, I don't understand.
The idea above was only for solving the question "am I installed ?" 
yes/no, not "where am I installed ?".

 
> > Not sure there is a simple tool to do that, but writing one shouldn't
> > be hard.
> 
> sed? :)

I have never used sed on binary files. Do

Re: [CMake] Best way to handle application data path for local run vs. installation

[Alexander Neundorf]

On Tuesday, December 01, 2015 07:17:35 Ruslan Baratov wrote:
> On 01-Dec-15 03:51, Alexander Neundorf wrote:
> > On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake 
wrote:
> > > On 30-Nov-15 09:10, Dmitry Marakasov wrote:
> > > > Hi!
> > 
> > ...
> > 
> > > > The best solution would be for cmake to fix path in executable 
file
> > > > 
> > > > right after installation, something similar to what cmake does 
with
> > > > 
> > > > rpaths.
> > > 
> > > I doubt there is a general way to patch data section with string in
> > > 
> > > executable. At least with different size and in safe manner. For 
example
> > > 
> > > Clang is smart enough to figure out 'strlen' of literal string at
> > > 
> > > compile time, so changing string affects logic and hence is 
dangerous.
> > > 
> > > And rpaths unlike data is designed to be modifiable
> > 
> > Not really. CMake has extra code to make sure the build rpath is as
> > long as the install rpath will be, so it can be patched in later.
> 
> Well, that's exactly what I said - RPATH can be patched.

well, the RPATH entry was not designed to be patched, any other string 
in an executable could be patched too:

const char* my_builddir_flag = "_I_M_NOT_INSTALLED_";

...
if (*my_builddir_flag)
{
   ... code when not installed
}
else
{
   ... code for the installed version
}



Just search for that string in the executable and replace the first byte 
with a '\0'. Not sure there is a simple tool to do that, but writing one 
shouldn't be hard.
Maybe it would even be accepted as an option into cmake.

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

Re: [CMake] Best way to handle application data path for local run vs. installation

[Alexander Neundorf]

On Monday, November 30, 2015 16:13:03 Ruslan Baratov via CMake 
wrote:
> On 30-Nov-15 09:10, Dmitry Marakasov wrote:
> > Hi!
> > 
...
> > The best solution would be for cmake to fix path in executable file
> > right after installation, something similar to what cmake does with
> > rpaths.
> 
> I doubt there is a general way to patch data section with string in
> executable. At least with different size and in safe manner. For 
example
> Clang is smart enough to figure out 'strlen' of literal string at
> compile time, so changing string affects logic and hence is 
dangerous.
> And rpaths unlike data is designed to be modifiable 

Not really. CMake has extra code to make sure the build rpath is as long 
as the install rpath will be, so it can be patched in later.

> (e.g. see
> install_name_tool for OS X) so it's okay to hack it back and forth.
> 
> Second thought is that when you hardcode path in executable you 
make it
> non-relocatable. 

E.g. on Linux $ORIGIN could be used in the RPATH.

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

Re: [CMake] Benchmarking with CMake

[Alexander Neundorf]

On Friday, November 13, 2015 14:41:35 Nagy-Egri Máté Ferenc via 
CMake wrote:
> Thank you all for your resonses,
> 
> My use case is that I have a set of executables that function as unit 
tests.
> Currently I use the return value of the .exe as a means of indicating
> success, though I know there is way to match std::cout against a 
regex for
> more complex tests. However, the timings of the tests are not always
> suitable for benchmarking, because I only want the timings of a 
particular
> part of the tests. Their initialization times are comparable to their
> runtimes. While I could tune a parameter so that the init phase is
> negligable, but then benchmarking would take for ages. I want to write
> benchmark executables (similar to unit tests) that write a single 
number to
> the console and nothing else. Run some command (make bench?, 
cbench?) which
> runs, these tests, fetches the sole number from the std::cout and 
prints
> those numbers as output instead of the total run time presented by 
ctest.
> 
> @Peter: I also encountered Google Benchmark. I have already seen 
it’s output
> and is perfectly fine. I am however a bit reluctant to grab another
> dependency that all my consumers would be advised to install. 
CMake is a
> fairly full blown suite and I was hoping to find something that could
> provide similar results.
> 
> @Matt: Seems nice. Python is not much a dependency, but VTK is 
less evident
> to be present on all machines.
> 
> @Alexander: I still have to look into this, because information seems a
> little scarce on doing it. It seems to me, that CDash has to be installed
> somewhere to be able visualize the data. 

Yes.

> Is there a way to generate the
> HTML-r for local consumption instead of submitting somewhere? 
(Ideally
> bypassing a local installation of CDash)

I don't think so.

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

Re: [CMake] Benchmarking with CMake

[Alexander Neundorf]

On Monday, November 09, 2015 23:21:58 Nagy-Egri Máté Ferenc via 
CMake wrote:
> Hi!
> 
> Can anyone tell me if CMake (or CTest) can be customized in a way to 
produce
> decent benchmark output? An .xlsx perhaps, or something GnuPlot 
friendly? I
> have not found any examples of CTest being (ab)used in this way.
> 
> Is my feeling correct, that this should be something like CBench?


depending on what you want...
You can make your test output  tags, and cdash will 
create graphs from the measured numbers. I think they can also be 
exported to csv.

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

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

[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] Is the situation with CMake + Eclipse ever going to get any better?

[Alexander Neundorf]

Hi,

On Sunday, September 27, 2015 13:29:15 Talin wrote:
> I've been using CMake and Eclipse for a bunch of different projects over
> the last several years. Although many aspects of both CMake and Eclipse
> have improved over the years, using them together still has a lot of
> problems.
> 
> From what I understand, you have three choices when setting up a project:
> 
> 1) Use in-source builds.
> 2) Use out-of-source builds with a single generated project.
> 3) Use out-of-source builds with both a build project and a source project.

the problem is that Eclipse does not support a directory layout where the 
project file is not the root of the source directory.

In my simplistic view it would be a simple
 tag in the .project file, and Eclipse would afterwards use that 
directory as root directory.

If something like that would be done in Eclipse, all those problems would be 
solved.

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

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

[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] linking: absolute path vs -l

[Alexander Neundorf]

On Wednesday, September 02, 2015 22:12:39 Nico Schlömer wrote:
> Indeed,
> ```
> get_target_property(out ${netCDF_LIBRARIES} LOCATION)
> message(${out})
> ```
> gives
> ```
> /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0
> ```
> This value appears to be set in the CMake export file
> ```
> /usr/lib/x86_64-linux-gnu/cmake/netCDF/netCDFTargets-none.cmake
> ```
> What does this mean?

this means that netcdf is a so-called "imported target".
I.e. for cmake, it is a library target, as those which are created when doing 
add_library(foo foo.c bar.c blub.b),
but hass not been built by the project, but has been built and installed 
before, and then during find_package() an "imported" target has been set up, 
which has all necessary target properties set so it can be used the same way a 
target which has been built inside cmake.

Maybe absolute paths of imported targets are handled differently, I'm not 
sure.

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

Re: [CMake] linking: absolute path vs -l

[Alexander Neundorf]

On Wednesday, September 02, 2015 20:28:35 Nico Schlömer wrote:
> Curiously,
> ```
> message(${ZLIB_LIBRARIES})
> message(${netCDF_LIBRARIES})
> ```
> yields
> ```
> /usr/lib/x86_64-linux-gnu/libz.so
> netcdf
> ```
> Hm, I would have expected it the other way around. :)


maybe "netcdf" is the name of an imported target.
Can you check that (e.g. by trying to get a target property from it and if so 
, figure out the attached location ?

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

Re: [CMake] linking: absolute path vs -l

[Alexander Neundorf]

On Wednesday, September 02, 2015 08:22:08 Nico Schlömer wrote:
> > it uses -l if the full path is not know or if the full path is one of the
> > system
> library dirs
> 
> Hm, that sound a little weird. Using `-l` appears to delegate the library
> finding to the linker although CMake has already done that job. If one was
> overly cautious, one could ask questions like: What if there are two
> libraries by the same name in different system library dirs? What if
> there's only one library in a system dir at configure time, but two at link
> time?
> 
> Moreover, in the example I gave above it seems that both libraries are in
> the system path, yet still they are represented differently on the link
> line.

what values do ${ZLIB_LIBRARIES} and ${netCDF_LIBRARIES} have in your case ?

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

Re: [CMake] Crawling documentation to find named argument keywords

[Alexander Neundorf]

On Monday, August 17, 2015 09:15:18 Michael Jackson wrote:
> I thought there used to be a DocBook version of the documentation? At one
> point I had an XML parser that used that as input to process the
> documentation in the same way.

the way the documentation is generated has changed with version 3.0 I think, 
cmake now is sphinx-based. I'm not quite sure whether it still supports 
docbook.

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

Re: [CMake] linking: absolute path vs -l

[Alexander Neundorf]

On Friday, August 28, 2015 08:23:47 Nico Schlömer wrote:
> Hi everyone,
> 
> I'm curious about when CMake decides to link a library by its absolute path
> and when it links using the `-l*` syntax. I came across this for the very
> simple test problem
> ```
> cmake_minimum_required(VERSION 3.0)
> 
> project(mytest)
> 
> find_package(ZLIB REQUIRED)
> find_package(netCDF REQUIRED)
> 
> add_executable(mytest main.cpp)
> target_link_libraries(
>   mytest
>   ${ZLIB_LIBRARIES}
>   ${netCDF_LIBRARIES}
>   )
> ```
> The resulting link line is
> ```
> /usr/bin/c++   CMakeFiles/mytest.dir/main.cpp.o  -o mytest -rdynamic
> -lz /usr/lib/x86_64-linux-gnu/libnetcdf.so.7.3.0
> ```
> so ZLIB is linked with `-lz`, netCDF with the full absolute path.
> 
> Seems inconsistent? (ZLIB by the way is found through CMake's
> FindZLIB.cmake, netCDF by their own export files.)
> 
> So far, I had been under the impression that `-l*` defeats the purpose of
> CMake a little bit as it asks the linker to search in the system's paths
> for a libz.so, something CMake has already done.
> 
> A little clarification here would be great.

it uses -l if the full path is not know or if the full path is one of the 
system library dirs (like e.g. /usr/lib/ or the, IIRC, $LIBRARY_PATH env.var)

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

Re: [CMake] [cmake-developers] CMake IR

[Alexander Neundorf]

On Wednesday, July 29, 2015 07:49:07 Nagy-Egri Máté Ferenc via cmake-
developers wrote:
...
 I believe CMake is an invaluable tool, but it could do far better. 0/10
 CMake users I’ve met say they are “happy” CMake users. The learning curve
 is steep, and the skills gained are not reusable. CMake could gain even
 greater momentum (not by ditching, but) by offering alternate input
 languages with entities (classes, functions, macros, etc.) that feel
 natural in the given context.

Well, the cmake language is not really pretty, but in my experience it is 
usually good enough. Having a somewhat better language like e.g. Lua may be a 
good thing.
There is actually an advantage in not thaving a full-featured scripting 
language: users are less tempted to turn the build scripts into actual 
programs containing logic and doing a lot of stuff.
I have seen that happen with scons builds... as developer you had to 
understand two programs: the actual software, and the build program.

There were already experiments with Lua and also with Javascript for cmake, 
but they didn't succeed so far.

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

Re: [CMake] linking static libs into shared libs on Linux

[Alexander Neundorf]

On Tuesday, July 07, 2015 14:36:25 Steve Borho wrote:
 Hello, I am the technical lead for x265 (HEVC encoder) and we have used
 cmake successfully since the beginning of the project.  There are a few
 rough edges that we've had to work around (uninstall rules, yasm support
 in MSVC, etc) but in general it has worked pretty well.
 
 x265 can support a number of bit-depth options, but these are compile
 time decisions. You must chose at build time whether the encoder will
 use 8bit, 10bit, or 12bit color samples internally.  Recently we've
 resolved the naming conflicts and thus allow these multiple builds of
 libx265 to be linked together into a single binary.
 
 The way the multilib build process currently works is it creates 8bit/
 10bit/ and 12bit/ folders, then runs cmake in each seperately (with
 different options) so there are three distinct build folders. It builds
 10bit and 12bit first, outputting only static libraries, then finally it
 builds the 8bit folder and adds the 10bit and 12bit static libraries to
 the 8bit shared library link target.
 
 This works well on Windows and Mac but on x86_64 Linux I get this error:
 
 /bin/ld: common/CMakeFiles/common.dir/x86/pixel-a.asm.o: relocation
 R_X86_64_PC32 against symbol `x265_pw_1' can not be used when making a
 shared object; recompile with -fPIC
 
 (in a nutshell, the 10bit and 12bit static libs are no longer position
 independent)
 
 I figure there are multiple potential solutions for this and would
 welcome pointers for any of them
 
 1 - is there a way for the project to re-include itself? If so we could
   have the 8bit build simply build the 10 and 12bit object libraries and
   link with those directly and bypass the creation of static libraries.
   This would perhaps be optimal since you would end up with a single
   Makefile driving the whole build.
 
 2 - is there some invocation that will force cmake to build the static
   libraries such that they are still safe for linking into a shared
   library?
 
   I've already tried these unsuccessfully:
 set(CMAKE_POSITION_INDEPENDENT_CODE TRUE)
 set_target_properties(x265-static PROPERTIES POSITION_INDEPENDENT_CODE
 TRUE) set_target_properties(x265-static PROPERTIES LINK_FLAGS -fPIC)
 
 3 - is there another intermediate format that cmake can output that
   preserves -fPIC, or some way to access the object libraries of the
   other external builds?
 
 4 - is there any post-processing that can be done on the static libs to
   make them safe for shared libs again (guessing this is not likely)

did you already have a look at the object libraries (created using 
add_library(... OBJECT...) ? Those basically just build the object files, and 
can later be used to link into other targets.

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

Re: [CMake] warn if features used that require cmake-x.y

[Alexander Neundorf]

On Friday, July 03, 2015 09:33:42 Glenn Coombs wrote:
 I don't think policies are sufficient.  I just tried using the new
 target_sources command that was introduced in CMake 3.1.0 in a
 CMakeLists.txt file that specified cmake_minimum_required(VERSION 3.0) and
 it didn't warn that the CMakeLists.txt file wouldn't work with CMake 3.0.
 I think if you want to guarantee that it will work with CMake x.y then you
 must always use CMake x.y instead of using newer versions and hoping they
 will tell you if you have used something that won't work on the older
 version you require.

...or a nightly build using the minimum required versions of everything the 
project needs.

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