Re: [CMake] Should header files be listed for a target?
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
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] link only with targets feature
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
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
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] Default library name?
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
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
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
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)
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)
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
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
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
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
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
[CMake] How to handle dependencies of protobuf files ?
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] How to build CMake so it works on an older Linux?
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?
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?
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?
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?
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
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] [cmake] [RFC] rewriting FindMKL
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] RPATH for pkg-config
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
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
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(&argc, &argv, 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] rebuild externalprojects
On 2017 M09 21, Thu 07:18:46 CEST David Cole via CMake wrote: > By manually deleting (or touching) the stamp file associated with the > earliest step you need to re-run. > > ExternalProject is not for auto-detecting changes to stuff and > minimally re-running build steps. It's for static stuff that doesn't > change much. > > Find the "-build" stamp file that's associated with the project > containing the source you changed and delete it. > > Then run the build from the top and that one and everything that > depends on it afterwards should rebuild. so, if I have an "external project" as sources in my project (i.e. it is not updated from some other repository or something), and if then that package is upgraded to the next version, what's the recommended way to enforce a rebuild of it ? I have only found two clunky work-arounds: if it's a cmake-based project, I just add --no-warn-unused-cli -DREBUILD_FLAG=123 to CMAKE_ARGS, and increase this "REBUILD_FLAG" whenever a rebuild is necessary. What also seems to work is to misuse the URL_MD5, and set it to the date of the last update, e.g. URL_MD5=20171002 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] Debugging find_package() search behavior?
On 2017 M10 1, Sun 12:38:43 CEST David Cole via CMake wrote: > No, I was already promptly corrected by Brad, too. I was not > accounting for the fact that the other find_* calls used inside of > find modules also use CMAKE_PREFIX_PATH. I was thinking of its use to > find a project's config file from the find_package config mode. > > I stand corrected. Again. ;-) yeah, sorry, I had problems with receiving mail from the cmake list since August and was catching up yesterday and replied too quickly. 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] Advice on converting legacy project to modern CMake
On 2017 M08 10, Thu 17:15:00 CEST Robert Maynard wrote: > > Which leads to a question I have for the Kitware types here. What > > should I suggest to my Linux enterprise distribution users? Can they > simply download and use the latest Linux binary version of CMake that > is distributed by Kitware or are there library version > incompatibilities that make that option non-viable? Alternatively, if > such users want to build modern CMake for themselves can they do that > or do system library incompatibilities stop them in that case as well? > > The official CMake binaries are built using a static libstdc++ and > static glibc so they should be able to work on any x86_64 linux > machine. it starts to be a bit different once you want to use also cmake-gui, then the requirements a a bit higher. I think at 3.7 or something it defaults to Qt5 and xcb, and that is not available on really old systems (RHEL5). 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] debugging CMAKE_PREFIX_PATH
On 2017 M09 13, Wed 09:50:48 CEST Patrick Welche wrote:
> I think I am confused by the following:
>
> 1) CMAKE_PREFIX_PATH;
>
> Problematic (scribus) CMakeLists.txt:
>
>set(CMAKE_PREFIX_PATH "${QT_PREFIX}/lib/cmake")
This looks wrong to me.
In general CMAKE_PREFIX_PATH should contain only the base install directory of
packages, and not point into the library dir etc. So it should more look
something like this:
set(CMAKE_PREFIX_PATH "${QT_PREFIX}")
But actually this should be left to the user, since he knows where Qt is used
(or is supposed to know).
> CMakeCache.txt:
>
> //No help, variable specified on the command line.
> CMAKE_PREFIX_PATH:PATH=/usr/pkg/qt5
>
> So the problem was that CMakeLists.txt overwrote the command line.
> Removing the set() line made things work
Yes. A "normal" set() call overrides values coming from the cache.
> 2) CMAKE_MODULE_PATH
>
> CMakeLists.txt (with extras to debug):
>
> set (CMAKE_MODULE_PATH
> "/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-Modules" "one"
> "two" "/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-Modules"
> "${CMAKE_SOURCE_DIR}/cmake/modules") set(testpath ${CMAKE_MODULE_PATH}
> CACHE PATH "testing path")
>
> CMakeCache.txt:
>
> //No help, variable specified on the command line.
>
> CMAKE_MODULE_PATH:PATH=/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlin
> k/cmake-Modules
>
> //testing path
>
> testpath:PATH=/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-M
> odules;one;two;/usr/obj/pkgsrc/print/scribus5/work.x86_64/.buildlink/cmake-M
> odules;/usr/obj/pkgsrc/print/scribus5/work.x86_64/scribus-1.5.3/cmake/module
> s
>
> So here, it seems the command line overwrites CMakeLists.txt ?!
Ehm, doesn't testpath in the CMakeCache.txt have the contents of
CMAKE_MODULE_PATH from the CMakeLists.txt ?
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] Debugging find_package() search behavior?
On 2017 M08 29, Tue 11:33:15 CEST David Cole via cmake-developers wrote: > That's correct: > > find modules do what they want, and most do not pay attention to > CMAKE_PREFIX_PATH. are you sure ? As long as NO_DEFAULT_PATH is not used in the find_*() calls, CMAKE_PREFIX_PATH is used automatically by them. 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 practice for modifying search path for find_package()
On 2017 M08 24, Thu 13:36:45 CEST Robert Dailey wrote: > So I have a "super build" CMake script that runs a series of > ExternalProject_Add() functions to execute builds of various third > party libraries and install them to a path relative to the parent > project's CMAKE_BINARY_DIR. > > Once the parent project generation occurs, it is expected to do a > series of find_package() commands to locate the packages installed by > the previous super build. > > What is the best way to intercept the find_package() search paths to > prioritize searching to the custom relative root directory managed by > the super build? Based on the documentation for find_package()[1], > seems like CMAKE_PREFIX_PATH might be the best way (set it as a normal > variable, not a cache variable) inside the CMake scripts prior to the > find_package() invocations (which are done indirectly by other CMake > scripts I do not manage and cannot change). Although, the usage intent > for CMAKE_PREFIX_PATH seems to be documented differently than how I > plan to use it. You have one install dir for your external-package libraries and then want to use them ? IMO using CMAKE_PREFIX_PATH is just fine 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Feature request: change how CMake chooses compiler when Ninja is used (Windows)
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] cdash/ctest question
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)
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)
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)
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] Function declaration scope
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
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
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
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] How to check if Eclipse CDT4 generated project is set up correctly?
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
Re: [CMake] Code::blocks: parallel build from IDE
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 > > > > > 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
Re: [CMake] Incorporating cmake dir into configure.ac, but it depends on a autconf-managed in-tree library
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] Finding Packages Installed in Non-Standard Locations
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
On Sunday, January 17, 2016 13:45:34 Dimitri Kaparis wrote: > On Sat, Jan 9, 2016 at 9:16 PM, Alexander Neundorf > 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] cdash/ctest question
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] Code::blocks: parallel build from IDE
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
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
Re: [CMake] Making CMake *not* use -isystem at all
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
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
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
Re: [CMake] Best way to handle application data path for local run vs. installation
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
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
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
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] Is the situation with CMake + Eclipse ever going to get any better?
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] linking: absolute path vs -l
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
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
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] linking: absolute path vs -l
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] Crawling documentation to find named argument keywords
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] [cmake-developers] CMake IR
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
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
On Thursday, July 02, 2015 04:13:40 Stuermer, Michael SP/HZA-ZSEP wrote: > Have a look at cmake_minimum_required() and cmake_policy(). I think with > these both it should be possible to verify you are using a cmake version > that provides all features which are required by your project. no, what he is talking about is the other way round. He wants to make sure nobody accidentially introduces cmake code which requires a newer version of cmake than what cmake_minimum_required() states. I think that's really hard to implement, but it would be nice to 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] warn if features used that require >cmake-x.y
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
Re: [CMake] Automatic management of Eclipse projects
On Monday, June 22, 2015 18:02:01 Cedric Doucet wrote: > Hello, > > I am testing the possibility of generating Eclipse projects with CMake. > I use the following command line: > cmake -G"Eclipse CDT4 - Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug ../src > It works fine. > > However, I would like to go further in this direction. > - What could I put in CMakeLists.txt to not to have to pass the "-G" option > to cmake? Currently you have have to use -G, or use cmake-gui. Support for a cmake-specific environmnent variable like CMAKE_DEFAULT_GENERATOR could be added. > - How could I be able to switch between debug and release modes > in Eclipse? Generate two build trees (projects), and import them both in 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] cross compiling with sdcc
On Saturday, June 13, 2015 23:26:59 tors...@robitzki.de wrote: > Hi Alex, > > Am 13.06.2015 um 22:18 schrieb Alexander Neundorf : > > On Friday, May 29, 2015 11:14:06 tors...@robitzki.de wrote: > … > > >> I saw that there is a file Platform/Generic-SDCC-C.cmake, while searching > >> for a way to force cmake to use this file, I found a makro > >> CMAKE_FORCE_C_COMPILER that let me override the compiler detection. > > > > … > > you shouldn't have to use cmake_force_c_compiler(). > > You did try setting up a toolchain file which points to sdcc ? > > could you elaborate on this solution? Would the > Platform/Generic-SDCC-C.cmake file that is shipped with a normal cmake > installation such a toolchain file? here is some documentation on this: http://www.cmake.org/cmake/help/v3.2/manual/cmake-toolchains.7.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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] determining which system headerfile provides a given function
On Saturday, June 13, 2015 23:17:37 René J.V. Bertin wrote: > On Saturday June 13 2015 22:26:12 Alexander Neundorf wrote: > > did you try check_symbol_exists() and the other similar functions ? > > Yes, but none that I could find give any information beyond whether the > symbol exists. It may be possible (or necessary) to repeat such tests > trying each of the possible candidate header files in succession until a > hit is found, but as I said in my initial email, that doesn't work. That's > about all there's to say about it: I presume this approach doesn't work > because of caching intended to avoid testing the same thing twice. if you have multiple candidate headers, try them all, and use separate result variables for every one. Is that the problem 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: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] How does :: actually works?
On Thursday, June 11, 2015 19:18:55 Klaim - Joël Lamotte wrote: > On 11 June 2015 at 15:22, Johannes Zarl-Zierl > > wrote: > > Hi, > > > > > I tried several times now to find documentation about how to define > > > and use target names which seem to have namespaces, like Qt ones. > > > > > > For example: add_executable( MyProject::some_target ... ) > > > > AFAIK target namespaces are intended for imported targets, not "regular" > > targets: > > > > "A NAMESPACE with double-colons is specified when exporting the targets > > for > > installation. This convention of double-colons gives CMake a hint that the > > name is an IMPORTED target when it is used by downstreams with the > > target_link_libraries() command. This way, CMake can issue a diagnostic if > > the > > package providing it has not yet been found." > > [1] > > > > > > [1] > > http://www.cmake.org/cmake/help/v3.3/manual/cmake-packages.7.html?highligh > > t=namespace > > > > > > I can't find any documentation or even name for this. > > > > > Is it considered a "namespace"? > > > In any way I found nothing specific to this syntax in the wiki. > > > > The concept is called "namespace" in cmake, just as you assumed. I don't > > know > > if there's anything about it in the wiki, but the official documentation > > has a > > (very) short description in the cmake_packages[1] page, as well as in the > > documentation for the export command. > > (sorry I was actually thinking about the documentation and typed "wiki") > > Thanks, it was not totally clear that the definition of the namespace is > done > in another operation, so I assumed that it was just a local option, not ana > actual language feature, > and simply dismissed it. > Maybe the concept should have it's own section? > There is no mention of this in the language page. Or is it really useful > only if you are writing exports? > > Anyway thanks, it's clearer now. What do you actually want to do with the "namespace" ? cmake does not really have namespaces, what the documentation talks about is only used as a hint when using imported 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] determining which system headerfile provides a given function
On Wednesday, June 10, 2015 01:32:21 René J. V. Bertin wrote: > Ok, let me rephrase the question to see what other kind of constructive > answers that'll lead to: > > how does one check which header file provides the prototype for a function > from the system libraries? Function in question: reallocf; can apparently > be in either stdlib.h or bsd/stdlib.h . did you try check_symbol_exists() and the other similar 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
Re: [CMake] How to choose a compiler different from default?
On Sunday, June 07, 2015 17:39:39 Peng Yu wrote: > Hi, I following the following steps to compile gtest. > > https://code.google.com/p/tonatiuh/wiki/GoogleTest > > But the following output shows that it uses the default compiler on > Mac OS X. I want to use some other compiler. Does anybody know how to > instruct cmake to do so? Thanks. did you try setting the CC/CXX environment variables to point to the compiler you want before running cmake initially ? 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] cross compiling with sdcc
On Friday, May 29, 2015 11:14:06 tors...@robitzki.de wrote: > Hello, > I was looking for some resources on how to configure cmake to use the small > device c compiler (sdcc). I tried a little bit and found that cmake assumed > that the object file extension would be .obj. But sdcc uses .rel for object > files. I’ve searched a lot in the web and the cmake sources, tried to > figure out, how the compiler detection mechanism works. > > I saw that there is a file Platform/Generic-SDCC-C.cmake, while searching > for a way to force cmake to use this file, I found a makro > CMAKE_FORCE_C_COMPILER that let me override the compiler detection. > > So now I have a working solution and wonder if that solution is one > „correct“ solution. „correct“ in terms of supported and intended by the > developers. > > cmake_minimum_required(VERSION 3.2) > include (CMakeForceCompiler) > set(CMAKE_SYSTEM_NAME Generic) > CMAKE_FORCE_C_COMPILER(sdcc SDCC) > > project(test C) > > Does this looks reasonable? Thank you very much for your time! you shouldn't have to use cmake_force_c_compiler(). You did try setting up a toolchain file which points to sdcc ? 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] What is the proper way to export targets that will be split into separate binary packages?
On Friday, April 24, 2015 12:33:50 Alan W. Irwin wrote:
> The Fedora packager of PLplot is having trouble splitting installed
> results into separate binary packages because of the way that PLplot
> currently exports its targets. What steps do we have to do to make
> life easier for him?
>
> Here is the typical code we use now to export our targets.
>
> # Done only once
> install(EXPORT export_plplot DESTINATION ${LIB_DIR}/cmake/plplot)
>
> # Done for each different PLplot library target we want to export
> install(TARGETS
>EXPORT export_plplot
>ARCHIVE DESTINATION ${LIB_DIR}
>LIBRARY DESTINATION ${LIB_DIR}
>RUNTIME DESTINATION ${BIN_DIR}
>)
>
> # Done for each different PLplot executable target we want to export
> install(TARGETS
>EXPORT export_plplot
>DESTINATION ${BIN_DIR}
>)
>
> As a result of these commands, $prefix/lib/cmake/plplot contains
> three files:
>
> export_plplot-noconfig.cmake, export_plplot.cmake, and plplotConfig.cmake
>
> I can find no reference to the noconfig variant, but from the
> documentation, find_package(plplot) in Config mode will find
> plplotConfig.cmake which in turn includes export_plplot.cmake which
> has CMake logic that loops over _every_ exported target.
>
> For a completely separate build system (for our installed examples)
> we import all these targets using
>
> find_package(plplot)
>
> and that works well for individual use of PLplot where nothing is
> split out from the installation.
>
> However, that command does not work well for binary packagers of
> PLplot since those packagers generally split the installed files into
> a bunch of different binary packages (typically a core package and
> optional additional packages to add extra features to the core
> package). So if the Fedora packager, for example, splits out the
> octave component of PLplot into a separate binary package, then when
> that package is not installed, find_package(plplot) errors out (as a
> result of that loop over all exported targets) with
>
> CMake Error at /usr/lib64/cmake/plplot/export_plplot.cmake:163 (message):
>The imported target "plplot_octave" references the file
>
> "/usr/lib64/octave/site/oct/x86_64-redhat-linux-gnu/plplot_octave.oct"
>
>but this file does not exist. [...]
>
> What changes to the above export procedure and/or
> find_package(plplot ... ) command are recommended so that
> find_package(plplot ) just works when some split PLplot
> binary packages are not installed?
IIRC putting the targets which will end up in separate packages should be put
into separate exports.
To use everything later on using one find_package() call, you probably need
one "umbrella" config 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:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Running custom executable
On Tuesday, April 07, 2015 15:24:18 Daniel Dilts wrote: > Looking at the way these things work, it seems to me that the ideal > solution to my situation, if it is possible, is to do a > add_custom_command() for each source file, and then do a > add_custom_target() that has all of the custom commands as PRE_BUILD events. No, PRE_BUILD works only for Visual Studio generators according to the docs. I think you need to give the list of output files generated using add_custom_command() as DEPENDS to add_custom_target(). Alex -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Running custom executable
On Tuesday, April 07, 2015 13:22:30 you wrote: > > > > I have a custom executable that does some codegen to produce an > > > > > >> > > enumeration and a couple of tables. I need this to be run against > >> > >> each > >> > >> > > source file before actual compilation. It needs include directories > >> > >> and > >> > >> > > macro definitions from the build system. > >> > > > >> > > Is there a way to do this with a CMake build system? > >> > >> add_custom_command > >> > >> > > seems like it might work, but I need all runs of the custom > >> > >> executable to > >> > >> > > run before compilation begins. > >> > > >> > execute_process() might be what you want: > >> > http://www.cmake.org/cmake/help/v3.2/command/execute_process.html > >> > >> Hmmm, probably add_custom_command() or add_custom_target() is what he > >> wants. > >> Why does it have to run before the compilation begins ? > > The program will run once per source file, scan them, and generate a header > file that is necessary for compilation to succeed. You could create a add_custom_target(foo); make your actual target depend on it, so it is finished before the actual compilation starts using add_dependencies(). 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] Running custom executable
On Monday, April 06, 2015 21:19:57 Klaim - Joël Lamotte wrote: > On Mon, Apr 6, 2015 at 8:47 PM, Daniel Dilts wrote: > > I have a custom executable that does some codegen to produce an > > enumeration and a couple of tables. I need this to be run against each > > source file before actual compilation. It needs include directories and > > macro definitions from the build system. > > > > Is there a way to do this with a CMake build system? add_custom_command > > seems like it might work, but I need all runs of the custom executable to > > run before compilation begins. > > execute_process() might be what you want: > http://www.cmake.org/cmake/help/v3.2/command/execute_process.html Hmmm, probably add_custom_command() or add_custom_target() is what he wants. Why does it have to run before the compilation begins ? 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] CMP0026 - Disallow use of the LOCATION target property
On Tuesday, February 24, 2015 20:14:23 Stephen Kelly wrote: > Jifeng ZHANG wrote: > > Any idea when CMake 4.0 is planned to release? So we can get a general > > idea when the old behavior will stop working. > > What will you do when it is released and the LOCATION property does stop > working for build targets? Whatever it is, any reason not to do it now? Always a good reason not to do it now while it still works is that by not doing it now the saved time can be used to work on other things which really need to be done now, maybe on a deadline. Once it's not working anymore it really needs to be done, and then it will be done. Yes, this postpones a problem into the future, but that's not always a bad thing. 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 and Eclipse Luna
On Tuesday, February 17, 2015 10:28:26 Robert Ramey wrote: > I'm using CMake 3.02 through CMake GUI. > > I have a CMake project which I want to build using Eclipse Luna (the most > recent eclipse). But the GUI doesn't present me with that option. I tried > to use the latest one (Helios) but it seems that it won't work with this > option. > > What should I do in order to build my project with Eclipse Luna Helios should be Ok (I'll update it soon to add Luna). What doesn't 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
Re: [CMake] [ANNOUNCE] CMake 3.2.0-rc1 now ready for testing!
On Friday, February 13, 2015 15:12:33 Robert Maynard wrote: > I am proud to announce that CMake 3.2 has entered the release candidate > stage. the new format of the release notes is really nice :-) 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] lib/cmake vs share/cmake/Modules
On Tuesday, February 10, 2015 03:43:33 44ghnqv...@snkmail.com wrote: > Alexander Neundorf wrote at 21:34 +0100 on Feb 9, 2015: > > On Monday, February 09, 2015 18:23:41 44ghnqv...@snkmail.com wrote: > > > How does one who is making a package which installs .cmake files > > > decide whether to put them in .../share/cmake/Modules or > > > .../lib/cmake? Where are the docs about that? I've seen > > > examples of 3rd party packages doing both (e.g., pulseaudio in > > > lib/cmake/Foo & opencollada - in share/cmake/Modules). > > > > architecture-independent files, i.e. which could sit on a shared > > NFS drive and which could be mounted from hosts with any type of > > CPU architecture, go into share/, i.e. basically data or text > > files. Files which are architecture dependend, e.g. Config.cmake > > files for installed libraries, go into lib/. (in doubt, lib/ is > > the safe choice). > > I'm looking for official cmake docs that explain the difference > between the two locations from cmake's perspective (rather than > just guidelines reiterated from hier(7)). I'm not aware for any more official docs, and if there are some, I doubt that they would contradict hier(7). So, Config.cmake files for libraries into lib/, for packages which are e.g. header only or similar share/ it is. If there are Config.cmake files for libraries which ar in shared I would consider this a bug. 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] lib/cmake vs share/cmake/Modules
On Monday, February 09, 2015 18:23:41 44ghnqv...@snkmail.com wrote: > How does one who is making a package which installs .cmake files decide > whether to put them in .../share/cmake/Modules or .../lib/cmake? Where are > the docs about that? I've seen examples of 3rd party packages doing both > (e.g., pulseaudio in lib/cmake/Foo & opencollada - in share/cmake/Modules). architecture-independent files, i.e. which could sit on a shared NFS drive and which could be mounted from hosts with any type of CPU architecture, go into share/, i.e. basically data or text files. Files which are architecture dependend, e.g. Config.cmake files for installed libraries, go into lib/. (in doubt, lib/ is the safe choice). 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] Announcing a (potential) new CMake project!
On Monday, February 02, 2015 19:23:41 Jeremy Moles wrote: > Hello everyone! My name is Jeremy, and I've been working with AlphaPixel > (http://www.alphapixel.com) for the last 3 years. Similar to other > companies of the type, Chris (our CEO), gives the employees the > opportunity to frequently work on projects that don't always directly > relate to the contract work at hand. Lately we've been tossing around > the idea of working on a project related to CMake, and before I set out > to begin hacking, I wanted to ping the lists and make sure I'm not > duplicating existing work or putting effort into something that won't > ever see any use. It's a good idea, and you're not the first one with that idea. There were several before (http://www.cmake.org/Wiki/CMake:Module_Maintainers#Third-Party_Modules) , one of them extra-cmake-modules, which I started: https://projects.kde.org/projects/kdesupport/extra-cmake-modules/repository/revisions/master/show/modules I intended this to be a central place for additional cmake modules, with contributors also from outside KDE, and not really bound to KDE, but this didn't work out, and until today there are no contributors outside KDE and I have the feeling that it is now basically a "KDE library". Aynway, you may check on the kde-buildsystem mailing list (https://mail.kde.org/mailman/listinfo/kde-buildsystem) whether the maintainers want to cooperate. 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] target_link_libraries replacing fully-qualified library with -l
On Thursday, January 29, 2015 08:39:33 Chris Green wrote: > On 1/29/15 7:41 AM, Brad King wrote: > > On 01/28/2015 03:12 PM, Chris Green wrote: > >> target_link_libraries( /X/Y/libtbb.so) > >> > >> results in link.txt files containing -ltbb. > > > > This happens when the library is in an implicit link directory, > > or possibly when the library does not have an SONAME field set. > > Thanks for this, Brad. > > Assuming that the list of implicit link directories is internal to CMake > and nobody has added to it by mistake, then I'm guessing there's no SONAME: just to make sure: you did check that the library directory is not part of LIBRARY_PATH ? 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 Eclipse & Resource Filters
On Wednesday, January 28, 2015 12:56:24 Robert Dailey wrote: > Hello, > > I generate my project using Eclipse CDT4 - Ninja. I have a > subdirectory called "Third Party" under my source directory that > contains boost, QT, and a number of other very large libraries. I > notice that the C++ indexer in Eclipse processes files in these > directories and frequently locks up my machine or crashes. Indexing > takes up to 30 minutes if it decides to complete. > > Is there a way I can specify resource filters in CMake scripts? If I > can do this, I can tell Eclipse to ignore the directories I don't want > it to scan or care about. no, there's currently not. Please enter a ticket on http://public.kitware.com/Bug 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
Re: [CMake] target_link_libraries replacing fully-qualified library with -l
On Wednesday, January 28, 2015 14:12:03 Chris Green wrote: > Hi, > > I've been trying to run down a problem with our cmake-based build system > that appears to be a result of a target_link_libraries(...) invocation > taking a fully qualified shared library location and replacing it with > -l. Since we're trying very hard to avoid picking up unwanted, > older copies of this library from system areas, this is causing us quite > some angst. > > The command: > > target_link_libraries( /X/Y/libtbb.so) > > results in link.txt files containing -ltbb. > > I wasn't able to find anywhere in documentation that mentioned this was > a possible behavior of target_link_libraries, which is why it took us so > long to trace it down to this in particular. > > So, my questions: > > 1. Is this a bug? > 2. If not a bug, what is the rationale for this behavior, and under > what circumstances does this behavior get triggered? > 3. Is it possible to deactivate this behavior? > 4. If not, can it be made possible to deactivate this behavior? IIRC, this is done if the directory /X/Y/ is part of some environment variable, I think it was LIBRARY_PATH. 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] KDevelop Projects
On Saturday, December 13, 2014 00:08:44 ambreen haleem wrote: > In my main repository where my project reside, I created a sub-directory > called build. When I do cmake -G "KDevelop3", I do get a kdevelop project > in the build but it has no src files and most of the files in there are > cmake related. I'm on Ubuntu 14.04 and KDevelop4. > > How do I generate a usable KDevelop project. the project files are for KDevelop 3. Are you still using that version ? I would guess you are using version 4 of KDevelop. 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] Generate Eclipse project with support for c++ 11
On Friday, December 05, 2014 09:58:17 Luca Gherardi wrote:
> Hi all,
>
> I’m writing a CMake file for a project that should be compiled both in
> Ubuntu and OS X. I want to use eclipse as IDE, gcc and C++ 11.
>
> I read different threads that suggest how to enable C++ 11 in eclipse.
> According to them I included these lines in my CMake:
>
> set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -Wall")
>
> if (${CMAKE_EXTRA_GENERATOR} MATCHES "Eclipse CDT4")
> set(CMAKE_CXX_COMPILER_ARG1 "-std=c++11" CACHE STRING "C++ version for
> eclipse" FORCE) set(CMAKE_ECLIPSE_VERSION "4.3" CACHE STRING "Eclipse
> version" FORCE) endif (${CMAKE_EXTRA_GENERATOR} MATCHES "Eclipse CDT4”)
>
> However, eclipse still set a wrong value for the symbol __cplusplus (199711L
> instead of 201103L I guess). For this reason eclipse is not able to index
> C++ 11 features such as shared pointer. Therefore I get a syntax error also
> if the code compiles.
>
> Any idea on how can I address this issue?
please enter a ticket at http://public.kitware.com/Bug/
You could try to set the environment variable CXX to "g++ -std=c++11" and see
whether that works (didn't try).
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
Re: [CMake] Fwd: Error in compiling OKULAR using CMAKE
On Friday, October 24, 2014 11:49:55 Sahil Sehgal wrote: > Hello, > > I was trying to build Okular (KDE application) in IDE (QT-creator and > Kdevelop both). I did the following steps: > 1.) clonned the source code of Okular > 2.) loaded the source code in IDE > 3.) click on the build command. > > I got the following error > > > */home/sahil/my/New Folder/prog/okular/build> /usr/bin/cmake > -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_BUILD_TYPE=Debug > '/home/sahil/my/New Folder/prog/okular/'-- Found Qt-Version 5.2.1 (using > /usr/bin/qmake)CMake Error: The following variables are used in this > project, but they are set to NOTFOUND.Please set them or make sure they are > set and tested correctly in the CMake files:QT_QT_INCLUDE_DIR the Qt include dir has not been found. Do you have the Qt development packages installed ? 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 Error: install(EXPORT "A" ...) includes target "b" which requires target "c" that is not in this export set, but x times in others.
On Wednesday, October 08, 2014 18:40:53 Nico Schlömer wrote: > Hi all, > > in on CMake project of mine, all seems to configure fine until the > very end where I'm getting error messages like > ``` > CMake Error: install(EXPORT "A" ...) includes target "b" which > requires target "c" that is not in this export set, but x times in > others. > ``` > First of all, CMake does seem to create all files necessary for > building the project, since that goes without error. Hence, I'm not > really sure CMake yells at me. > Second, I don't really understand the message. Indeed, I have a couple > of export sets in my project, and the libraries there in depend on > each other. Why the target "c" need to be in the same export set as > "b"? It doesn't. If target c depends on target b, and target c is exported, cmake checks that target b is exported too. This is necessary so cmake can put the name of the exported "b" library into the dependencies of c. This is possible if b is exported in the same export set as c, or if b is in a different export set, but only in one. Then cmake can use the name of the exported target b as it is used in the other export set. If b is exported in multiple export sets, each of these export sets can use a different namespace, and it is not clear which of these different names for b should be used as dependency for c. If b is in only one export set, it will be used with the namespace as used there in the list of dependencies of c. 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(3.0.2) Eclipse project indexing issues under linux
Hi, thanks for your detailled findings. Can you please create a ticket in the bug tracker with this, so it doesn't get lost ? http://public.kitware.com/Bug Thanks Alex On Monday, October 06, 2014 14:30:06 Tushar Soni wrote: > Hi, > > After generating Eclipse projects and importing them, Eclipse is not > indexing all source files. I have detailed the issue (so sorry for the long > email) and the experiments I have performed to resolve the issue. I would > be really glad if someone could point out, what is going wrong or is there > some bug? > > Not to go in too much details, here is how my directory (project) structure > looks like in order to explain the issue in more details: > > Sources: > > > *$someDir/common/project_a/src/source_a.cpp* > *$someDir/common/project_a/CMakeLists.tx*t -> Project A is a common lib, > uses by many tests > > *$someDir/tests/test_a/src/test_a.cpp* > *$someDir/tests/test_a/CMakeLists.txt* -> Includes the Project A using > add_subdirectory and creates a share object > > Cmake build directories: > *$someDir/cmakeOut/**common/project_a/* > *$someDir/cmakeOut/tests/test_a/* > > Cmake generated everything without errors and building the project using > make or Eclipse was not an issue. The issue is only when I import the > project in Eclipse (version 4.3.2) by *Import -> General -> Existing > Project -> $someDir/cmakeOut/tests/test_a/*, the indexer does not seem to > be working properly. It only indexes one source (test_a.cpp) whereas it > should index two (test_a.cpp + sourc_a.cpp). > > this is just an example setup, in my actual project, only 1 source file > gets indexed out of the 142 it should do. therefore it makes using Eclipse > very hard! > > Now this is what I noticed with my experiments. > > *Experiment 1*: Change cmake version and compare > > I used the exact same files and folder structure but changed the cmake > version to 2.8.10.2. The generated Eclipse project was able to index both > the source files! This was mind boggling. I have to use the cmake 3.0.2 > version, so I tried to narrow down the issue. > > When I did the diff of the .cproject created by the two cmake version I saw > this: > > cmake 3.0.2 has this in the .cproject > > ** > path=""/> > > cmake 2.8.10.2 has this in the .cproject > > > > The rest of the file is similar (except cmake path, which is obvious). > > *Success Result*: If I delete the line * *from the .cproject and then import the project, indexing > seems to be working!!! however I cant use this solution as my project is > not checked in and every body using it needs to make this step manually. > > *Experiment 2*: Change the import method > > After a lot of googling I found out that someone was suggesting to import > the project using this method (BTW, for totally different problem): *Import > -> C/C++ -> Existing Code as Makefile Project -> > $someDir/cmakeOut/tests/test_a/ *. When I did this, it again works! Mind > boggling yet again! > > Just by chance I found out that this method works because, by importing > this way Eclipse somehow modifies the .cproject and removed the lines like > I did in first experiment. > > *Conclusion*: So based on my experiments this line in the .cproject is > causing an issue with indexing: > ** > > I know most likely my conclusion is not correct but I do not have any other > explanation. Also I do not know why this line is actually the issue! > Therfore I am writing to you all to understand the issue a bit better. > Maybe the issue is elsewhere. > > Thanks in advance! -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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] TARGET_LINK_LIBRARIES with full path libraries
On Wednesday, September 17, 2014 14:50:40 Volker Pilipp wrote: ... > I suppose it is the line > LIBRARY_PATH=/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/opt/XXX/lib/g > cc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/:/lib/../lib64/:/usr/lib > /../lib64/:/opt/XXX/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../:/lib/:/ > usr/lib/ yes, cmake checks $LIBRARY_PATH and uses -l for the libraries located in these directories. I stumbled about that behaviour last year or so, I guess it's a feature. 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] install(EXPORT ...) includes target "B" which requires target "A" that is not in the export set
On Thursday, September 11, 2014 23:51:21 Nico Schlömer wrote: > Hi all, > > One of my projects contains two libraries libA and libB, where libB > depends on libA, and both are exporting their configuration through > the usual `INSTALL(EXPORT ...)` mechanisms. > I'm getting errors of the type > ``` > CMake Error: install(EXPORT "SEACASNemesis-exports" ...) includes > target "nemesis" which requires target "exodus" that is not in the > export set. > ``` > now, and I'm not quite sure what they mean. Do all of my export files > have to be self-contained? IIRC, it should complain if it detects that a target is needed which is not exported at 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] Platform information override file is ignored for ASM language
On Monday, August 25, 2014 14:36:21 Никонов Михаил Николаевич wrote: > Hello, > > In a bare-metal embedded project, I need to initialize compiler flags > to custom values while toolchains are initialized; for that, I'm using > override files to set _INIT variables. From what I've encountered, it > appears that CMAKE_USER_MAKE_RULES_OVERRIDE file (and > language-specific *_ASM one) are not loaded during initialization of > assembly compiler. Here's a test to reproduce it, made of two files: > > CMakeLists.txt: > set(CMAKE_USER_MAKE_RULES_OVERRIDE override.cmake) > project(Test C CXX ASM) > > override.cmake: > set(CMAKE_C_FLAGS_INIT "-Wall") > set(CMAKE_CXX_FLAGS_INIT "-Wall") > set(CMAKE_ASM_FLAGS_INIT "-Wall") > > After running cmake, CMAKE_C_FLAGS and CMAKE_CXX_FLAGS in > CMakeCache.txt contain flag -Wall, while CMAKE_ASM_FLAGS doesn't > (tested with CMake 2.8.12.2 and 3.0.1 and gcc 4.8.2 on latest Ubuntu). > > Is there any mistake I made? And if not, is there any elegant > workaround for that? I'm aware that I can just force flags' values > into cache in toolchain file itself, before project() call, but from > what I understood, it's a discouraged practice. please enter a bug report at http://public.kitware.com/Bug 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
Re: [CMake] How to deal with incompatible changes in interface of target_link_libraries()?
On Tuesday, August 12, 2014 09:06:13 Brad King wrote: ... > FYI, the only intended use case for setting a policy to OLD is to > quiet warnings in a maintenance branch of an existing release. > Some day support for OLD behavior of some policies may be dropped, > so all project development moving forward should set the policy > to NEW. Fixing a warning may make the project require the newer cmake version. E.g. if MyProject requires cmake 2.8.10, and there is a new policy in 3.0.0, which generates a warning, a developer using cmake 3.0.0 may see the warning and fix it, but by that he may have broken the build for the required 2.8.10 and actually now 3.0.0 is required. 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] Variable shadowing between scope, cache and command line argument
On Wednesday, July 30, 2014 14:59:46 Ghyslain Leclerc wrote: > Hello, > > First post here. Sorry if its too long. Simply trying to be as clear as I > can be. > > I am trying to make sense of the various ways to set a variable and how one > can shadow the other. Long story short, I am trying to get the following > behaviour for a variable in a script: > > 1 - check if MYVAR exists > 1.1 - If it does, test its validity and set a second variable > named MYVAR_VALID to TRUE or FALSE > > 2 - if MYVAR does not exist or if MYVAR_VALID is FALSE, inspect system for > information and set MYVAR (with FORCE in the cache) and MYVAR_VALID (not in > cache, but does not seem to make a difference). > > Hope this is written clearly enough to be understood. Sorry, english is not > my first language. Anyhow, I get the following behaviour easily except in > one case, which is the reason for my question. These are the cases I have > tested : > > - Start with empty cache and call ccmake. Then, MYVAR does not exist. My > script inspects the system, sets the value, sets MYVAR_VALID to TRUE and > stops. On successive runs, the variable is defined and valid, so the > system is not inspected again. Everything is fine. > > - Start with empty cache. Run it once, but can’t find a valid entry (or > find a wrong one somehow, but that’s practically impossible since the code > in my script to inspect the system and to test the variable are basically > the same. I digress, sorry). Set MYVAR_VALID to FALSE. User can set the > value to a valid one and on next run, the script will set MYVAR_VALID to > TRUE and then, we are back to variable defined and valid. Everything is > fine. > > - Start with "non-empty cache" because ccmake (or cmake) is called with > -DMYVAR:PATH="/Users/“, for instance. If the value set on command line is > fine, then MYVAR_VALID will be set to TRUE on the first run and no system > inspection is necessary. The value is now set and valid. Everything is > fine. > > Now, for my problem : > - Start with "non-empty cache" because ccmake (or cmake) is called with > -DMYVAR:PATH="/Users/“, for instance. But this time, the value is not a > valid one. Then, the variable is defined but not valid. So on the first > run, the script will inspect the system. If it can find a valid value, I > would like my script to override the variable with the valid one. Then, set > to valid and so on and so forth... > > I have not been able to do this. I can find the correct value, I can set > the new value, but it is not used. I mean by that that I have inspected > the CMakeCache.txt file and when I call ccmake, the cache contains the > value set on the command line. Then, I launch my cmake script and output > the values of MYVAR and MYVAR_VALID and they are respectively the one of > the command line and FALSE. Then, I find the correct value for MYVAR and > try and set it. When I inspect the cache, it seems the value has > effectively been overwritten. You are using set(... FORCE), right ? > But when I try to output the new variables, > it seems to remain stuck at the value provided on the command line. I have > tried using unset( MYVAR ) in scope, How do you mean that ? IIRC -DVAR=value sets the cache variable. Not sure, it seems -D maybe also sets the non-cache variable ? Then uset() should have worked. Can you post a small example to reproduce it ? 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] How to get rid of AUTOMOC: Checking ... messages
On Thursday, July 24, 2014 08:38:08 Dominique Ledit wrote: > Hi > > I currently use 2.8.12.2 CMake version and Qt 4.7.3 and set in my top-level > CMakeLists.txt the CMAKE_AUTOMOC to true Set (CMAKE_AUTOMOC on) > As a result, in the build log there are a lot of messages like: > > AUTOMOC: Checking > AUTOMOC: Checking > > Is there a way to get rid of them? Do you have VERBOSE enabled ? It should only be visible in this 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] how to add new source files in already build cmake project from inside eclipse cdt?
On Tuesday, July 22, 2014 04:03:44 Payal Prajapati wrote: > Hello, > Thank you for your reply. > Is there any way to build only my added file? because it takes much > time to rebuild the whole project even for a minor change in source > file? when you simply build (all, make all), only those file should be rebuilt which have actually changed. If everything is rebuilt everytime, something is 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
Re: [CMake] how to add new source files in already build cmake project from inside eclipse cdt?
On Monday, July 21, 2014 08:40:11 Payal Prajapati wrote: > hello All, > > Two things to say: > > 1)I read all conversion regarding this topic..but can any one explain me > the whole procedure? > 2)I am working on orfeo toolbox which i imported in eclipse.It works fine > upto make target->build step. but when i do make target->build->install and > then finish it gives me an error(highlighted with red mark on > projectname). can any one explain which steps are required for building > project after importing it in eclipse? > > Any help would be appreciable. you just have to add it to your CMakeLists.txt. Upon the next build, cmake will run again and regenerate the makefiles and Eclispe project files. You may need to manually refresh the project 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
Re: [CMake] How to build 'install' target or orther custom target in eclipse?
On Sunday, May 25, 2014 11:43:18 you wrote: > On Sun, May 25, 2014 at 9:18 AM, Alexander Neundorf > wrote: > > > > On Saturday, May 24, 2014 18:35:06 J Decker wrote: > > > So I've had to pick up eclipse to try and learn it; figured maybe if I > > > > took > > > > > my existing code and generated it as eclipse format I might get a better > > > clue. > > > > > > Now I can right click and bulid the project...but I don't see how to > > > > build > > > > > a specific target like 'install' > > > > more or less all available targets should be listed in the "Targets" tab. > > https://drive.google.com/file/d/0B812EYiKwtkkRWdnbHNVelVxZ0k > > Neither 'package' or 'install' show up... the screenshot shows the "Project explorer" tab, you need the "Make targets" tab. 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://www.cmake.org/mailman/listinfo/cmake
