Re: [CMake] find_package Config vs Module mode
Hi Joachim, Am Samstag, 20. Oktober 2018, 13:22:04 CEST schrieb Joachim Wuttke: > If Config mode is the newer, preferred way to find a package, I would expect > find_package to first try Config mode, and only fall back to Module mode if > no config scripts can be found. However, according to the find_package doc > page, it is just the other way round. > > Why? The reason as far as I understand it is that you, as the consumer of a library, might want to customize the find_package process. Since find_package modules are usually shipped by your own code[1], it's not a problem that the module eclipses the config package. > How to enforce that new config scripts are used if there are still FindXXX > modules around? First of all, purge the FindXXX modules from your own code base if you don't use them. Otherwise, append the "CONFIG" keyword to the find_package call as described in the docs[2]. If you want to keep the FindXXX module around for compatibility with older versions of a library, then an even better solution is to fix your FindXXX module to call find_package(...CONFIG) and skip the search if a config file is found. Cheers, Johannes [1] apart from the modules shipped with cmake [2] https://cmake.org/cmake/help/latest/command/find_package.html#full-signature-and-config-mode -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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
Am Dienstag, 7. August 2018, 14:48:26 CEST schrieb Randy Heiland: > Hmm, well if that's the case, how does one generate the HelloConfig.cmake > file? The official documentation is here: https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html > Although, for my particular situation, my question about wanting to > generate a "Find" file still remains, I think. I have a library which is, > potentially, useful to several projects. I assume there's some sort of > "Find" template for any such lib, i.e., a project needs to be able to > locate a lib (static or dynamic) and headers, cross-platform. Im almost positively sure that you don't want a FindXYZ.cmake, but a XYZConfig.cmake file instead. These are the main differences between Find- module packages and config-file packages: Find-Module packages: - are written and maintained independently of the "consumed" project (usually because the project does not support CMake) - are usually shipped by the consuming project - are hard to get right (they have to deal with strange installations, or old versions of the software, etc.) Config-file packages: - are generated by the "consumed" project - are shipped by the consumed project - have tooling to ensure correctness For the consuming project, there's no visible difference between both (you call "find_package(XYZ)" and cmake uses whatever it finds. In principle, it's even possible to use both together (note: please don't). That said, the official documentation can be a bit overwhelming at first. You probably can write some kind of cmake-2.6-style Find-Module package in less time, but the time to do it "right" is worth your effort. Just start by reading the documentation and don't hesitate to ask when you hit a problem… Cheers, Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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] Querying project dependencies from the UNIX command-line
Hi Ardi, Am Mittwoch, 18. Juli 2018, 11:31:50 CEST schrieb ardi: > For example, I'd like to type "somecommand /path/to/someproject" at > the UNIX command line, and get this output: > [...] > Furthermore, if another command could show optional requisites, it > would be really great: "anothercommand /path/to/someproject" > > Project /path/to/someproject can optionally use the following when being > built: > [...] > So, can I get this functionality from plain CMake/CPack ? Or would I > need additional tools (Note: I know about Hunter, but first I'd like > to know if plain CMake does already offer this feature). I don't think there's something that gives you exactly what you described, especially not for a random CMake project. If you can add some commands to the CMakeLists.txt, though, then the FeatureSummary module may suit your needs. Basically, you include the module an then add a cmake command like this: feature_summary(WHAT ALL FATAL_ON_MISSING_REQUIRED_PACKAGES) When you run cmake, you'll get a summary of which packages have been found/not found, and the required version if you supplied one for the corresponding find_package command. Cheers, Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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] Changes to cmake_minimum_required() for 3.12
Hi, Just giving my 2 cents: If the preferred solution is the "POLICY_NEW_UNTIL" wording, then why not make this accepted as well? This way, you can deprecate the backwards-compatible version in a few years and remove it some time thereafter. In the end, you'll get a cleaner solution... Cheers, Johannes On Montag, 2. Juli 2018 08:43:57 CEST Craig Scott wrote: > On Mon, Jul 2, 2018 at 4:04 AM, Alan W. Irwin > > wrote: > > On 2018-07-01 08:12+1000 Craig Scott wrote: > > > > Older CMake versions > > > >> will see the extra dots as being version component separators and will > >> end > >> up effectively ignoring the max part. > > > > This explanation of how "..." will be interpreted by older CMake > > versions makes sense, but it wasn't obvious to me without that > > explanation. And I suspect other build-system developers/maintainers > > would also benefit from the explanation. Therefore, please explicitly > > include the above explanation in the latest documentation of both the > > cmake_minimum_required and cmake_policy commands. > > I've updated the merge request to incorporate this feedback. > > https://gitlab.kitware.com/cmake/cmake/merge_requests/2180 -- Johannes Zarl-Zierl Information management JOHANNES KEPLER UNIVERSITY LINZ Altenberger Straße 69 4040 Linz, Austria P +43 732 2468 3898 johannes.zarl-zi...@jku.at www.jku.at -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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] conditions and included subprojects
he main project level > > > > > > - but if the sub project is being built standalone, the option is not > > defined and should be set e.g. in cmake-gui > > > > > > > > > > > > If I write now in the sub project > > > > > > > > > > > > IF(THAT_OPTION) > > > > > > ... > > > > > > > > > > > > this will be true if THAT_OPTION was set to ON in the main project. > > So far so good. But the expression is now so "clever" that it cannot > > distinguish between THAT_OPTION being set to OFF in the main project, > > or THAT_OPTION not being defined at all - like in a standalone build! > > > > > > > > > > > > One way would be to have an additional option or variable > > BUILDING_MAINPROJECT which is set to ON or TRUE in the main project > > and can be checked. However, I have so far not seen any > > CMakeLists.txt with such a code, so ... what are the experts doing in > > such a case? > > > > > > > > > > > > Thanks and regards, > > > > > > Cornelis > > > > > > > > > > -- Powered by www.kitware.com Please keep messages on-topic and check > > the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers > > various services to support the CMake community. For more information > > on each offering, please visit: CMake Support: > > http://cmake.org/cmake/help/support.html CMake Consulting: > > http://cmake.org/cmake/help/consulting.html CMake Training Courses: > > http://cmake.org/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 -- Johannes Zarl-Zierl Information management JOHANNES KEPLER UNIVERSITY LINZ Altenberger Straße 69 4040 Linz, Austria P +43 732 2468 3898 johannes.zarl-zi...@jku.at www.jku.at -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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] Contribute Find-module to CMake vs Config-file to upstream
On Dienstag, 22. Mai 2018 11:13:18 CEST Brad King wrote: > > not be much more work for the maintainer as pkg-config files. > > There is a proposal here: > > https://mwoehlke.github.io/cps/ This looks quite promising! Do you know whether there's a shared interest on the pkg-config and autotools side? Even without pkg-config joining the effort, it should be much easier to convince projects to create a .cps file than some "arcane" cmake-config scripts. Cheers, Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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] Contribute Find-module to CMake vs Config-file to upstream
Hi Mateusz, On Montag, 21. Mai 2018 19:39:16 CEST Mateusz Loskot wrote: > The FindLZ4 discussion basically ended with suggestion from Brad that, > instead of adding Find-module to CMake, I should approach LZ4 project > and add Config-file to the library itself. > Then I argued taht Config-files are more complex and I don't feel like > asking projects, which I don't maintain myself, to accept the extra > complexity There's more that we (as CMake community) could do to make it easier for non- cmake projects to add a config file, and I think this is a worthwhile goal. Currently, if the maintainer of an autotools-based project is willing to add a cmake config file, he or she basically needs to be an expert on cmake. There's no official template or guide on how to create a cmake config file without relying on a cmake module to do the work. If there was a good guide, or maybe even some tooling, cmake config files would not be much more work for the maintainer as pkg-config files. > I call CMake to accept *any* Find-module, filtering only based on > quality of CMake > idiomatic scripting. "Filtering based on quality" being the important part. > If CMake does not want Find-* modules within the source tree, then > - set up https://gitlab.kitware.com/cmake/find-modules > - move all existing Find-modules in there > - relax maintenance rules to accept *any* Find-module, provided > --- CMake scripting is decent quality (e.g no community downvotes or > rejecting reviews for period of quarantine) > --- CI passing tests > - finally, include the complete find-modules archive in the installer > so it is deployed >aside of CMake itself That seems like a reasonable way to deal with the situation. Maybe this would also encourage better quality of the (current) core find-modules. If you take a look at those, they are in wildly different shape regarding their quality. > If CMake does not care about Find-modules, it should not care or > should care about > them equally ACK. Cheers, Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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] Recommandations for public custom macro/functions installation
On Dienstag, 17. April 2018 13:48:39 CEST David Demelier wrote: > On Tue, 2018-04-17 at 12:25 +0200, Johannes Zarl-Zierl wrote: > > Just replying to this topic of your message: you may want to > > reconsider. The > > cmake gui allows you to group options automatically by prefix. This > > de-clutters > > the options considerably. > > I didn't know that! Nice catch. I'll reconsider using prefix then. I've > usually named my options WITH_FOO, do you recommend to use > PROJECT_WITH_FOO or WITH_PROJECT_FOO then? Personally, I prefer PROJECT_WITH_FOO because it also works when I have additional options PROJECT_ADDITIONAL_OPTION... Cheers, Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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] Recommandations for public custom macro/functions installation
Hi David, On Dienstag, 17. April 2018 11:58:12 CEST David Demelier wrote: > I personally do not want to prefix all my options in my project with > the project name prefix, I think that would be a bit ugly, and I do > want this macro to build and install the documentation. Just replying to this topic of your message: you may want to reconsider. The cmake gui allows you to group options automatically by prefix. This de-clutters the options considerably. On a related note: even without grouping, looking through the options of a project in ccmake or cmake-gui is so much easier when they are prefixed (and therefore easily identifiable). Cheers, Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/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 find_package() portably?
Hello Carsten,
On Samstag, 25. November 2017 11:46:44 CET Carsten Fuchs wrote:
> Thanks for your reply, but how can I proceed from here?
>
> In order to be able to write in the parent script something that works
> in either case, that is,
>
> target_link_libraries(main_program )
Well, that's one way, but that doesn't really provide any benefit above the
original solution (i.e. just define the JPEG_INCLUDES and JPEG_LIBRARIES
variables accordingly).
> it seems that I either
>
>- have to make a copy of FindJPEG.cmake, customize it to define
> target JPEG::JEPG and ship it along with my project,
Either that or you define it yourself:
find_package(JPEG)
if (JPEG_FOUND)
add_library(JPEG::JPEG UNKNOWN IMPORTED)
set_property(
TARGET JPEG::JPEG
PROPERTY IMPORTED_LOCATION ${JPEG_LIBRARIES}
)
set_property(
TARGET JPEG::JPEG PROPERTY
INTERFACE_INCLUDE_DIRECTORIES ${JPEG_INCLUDES}
)
endif()
I admit it's not a huge benefit over just using the variables. The advantages:
- you get slightly better error handling
- your target_link_libraries commands are slightly more readable.
>- or write my `../ExtLibs/libjpeg/CMakeLists.txt` so that it globally
> defines JPEG_LIBRARIES and JPEG_INCLUDE_DIRS
That will work, too.
Cheers,
Johannes
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware 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] Using find_package() portably?
On Mittwoch, 22. November 2017 11:32:22 CET Carsten Fuchs wrote: > That is, follow-up question: near the "..." above, we have got a target > "libjpeg", but how do I get the variables JPEG_INCLUDES, JPEG_LIBRARIES > etc. that `find_package(JPEG)` normally provides so that the last line > with the `target_link_libraries()` works? > I guess that defining them in `../ExtLibs/libjpeg/CMakeLists.txt` is wrong. You've found an ugly corner in CMake ;-) The problem in this specific case is that CMake ships with a FindJPEG module that does not define modern import libs, but uses the old way of defining _LIBRARIES and _INCLUDE_DIRS. IMO this highlights one of the main problems with find modules: nobody really maintains them. If JPEG had proper imported targets, your code could look like this: find_package(JPEG) # without "REQUIRED" if (NOT JPEG_FOUND) ... # Proceed with the shipped copy of libjpeg: add_subdirectory(../ExtLibs/libjpeg ../ExtLibs/libjpeg) endif() target_link_libraries(main_program JPEG::JPEG) You just have to make sure that your shipped libjpeg creates the proper namespaced target: add_library(JPEG ...) add_library(JPEG::JPEG ALIAS JPEG) HTH, Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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] Should configuration package files define module package variables?
Hi, On Freitag, 25. August 2017 11:21:50 CEST Robert Dailey wrote: > However, what I'm wondering is even though the import targets should > contain all information about include directories, libraries, etc, > should I still define the typical Foo_INCLUDE_DIRS, Foo_LIBRARIES > variables? This depends very much on the target audience of your config.cmake file. My personal opinion is that you can skip those variables entirely for new projects. (Somebody please correct me if I'm wrong!) > It seems like Module packages are being deprecated > in favor of Config packages, because it puts the responsibility of > maintaining find package logic on the upstream maintainer (config > package) instead of on CMake (module packages it ships with). Yes. This has been the case since cmake 2.8 or so. A general rule of thumb for module vs. config: If you are the upstream: create a config package. If the upstream is somebody else, but uses cmake: submit a patch and get them to provide a config package. If the upstream does not use cmake: they can still provide a config package. If all else fails: add a module to your project to find the upstream library. Cheers, Johannes P.S.: And yes: creating a config package has a steep learning curve. Link [2] has all the information you need, but it is hardly a nice tutorial... -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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] libsndfile in windows
On Dienstag, 21. März 2017 15:24:13 CET you wrote: > > Did you try asking on the libsndfile mailing list? > I did .but there was no response . Ok then. > I had written cmakelists.txt to compile and build . > I was able to successfully built it in linux , but in windows I was not > able to do it . > Do you have nay leads on that ? Reading the description that you linked to, I see that they have only done a partial port to cmake and still require autotools. If you want to compile on other platforms you'll need to get rid of those non-portable parts. I would probably look at any pull requests and issues for that repository and look for cmake-related reports. Maybe someone else is already fixing the issues? Otherwise, you can try porting the non-portable parts yourself and ask on this list if you have problems in your cmake code. Cheers, Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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] libsndfile in windows
Hi, On Dienstag, 21. März 2017 10:57:42 CET aishwarya selvaraj wrote: > I'm very new to all this , So Could anyone please guide me on what to do > next . Did you try asking on the libsndfile mailing list? They are more likely to know about the issue you're dealing with. Try here: http://www.mega-nerd.com/libsndfile/lists.html Cheers, Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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] cmp0065
Hi,
On Tuesday 05 July 2016 23:46:16 J Decker wrote:
> https://cmake.org/cmake/help/v3.4/policy/CMP0065.html
> while I like the idea it suggests, I don't use the flags for -rdynamic so
> this is meaningless to me
I'm not sure I understood you correctly, but if the policy is meaningless to
you, it shouldn't affect you...
> https://cmake.org/cmake/help/v3.4/prop_tgt/ENABLE_EXPORTS.html#prop_tgt:ENAB
> LE_EXPORTS
> SET_PROPERTY(TARGET ${project} APPEND PROPERTY COMPILE_DEFINITIONS
> TARGET_LABEL=${TARGET_LABEL};TARETNAME=\"${TARGETNAME}\" )
>
> or
>
> SET_PROPERTY( TARGET ${project} APPEND PROPERTY COMPILE_DEFINITIONS
> "CONSOLE_SHELL" )
>
> to indicate it's non-WIN32
First of all, there are the usual standard definitions provided by the
compiler, so you can just use
#if defined(WIN32)
#endif
to check whether the compilation happens for windows or another platform.
If you have the need for additional definitions, it seems to me that the usual
command:
target_compile_definitions( yourTarget PRIVATE COMPILE_SHELL)
https://cmake.org/cmake/help/v3.4/command/target_compile_definitions.html
Is that what you are searching for?
> I noted at the bottom of that the the default behavior will eventually be
> phased out... but then can we have some other flag to phase it back in?
You can always set policies to “OLD” to revert to the old behavior (until it
is finally phased out). In the case of cmp0065 the documentation explains what
you can do to have the same behavior with the policiy enabled:
Just set the ENABLE_EXPORTS property on the targets that need to export their
symbols.
HTH,
Johannes
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware 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] Version compatibility?
Hi Rob, I've stopped working on it when 3.0 came out. Since the whole thing was very much manual work (diff'ing documentation pages and checking whether some change was only better documentation or a real change in cmake), it was too much effort to continue long-term. Johannes On Saturday 23 April 2016 10:32:15 Rob McDonald wrote: > Is there a continuation of the CMake version -- feature mapping table? > > https://cmake.org/Wiki/CMake_Version_Compatibility_Matrix > > I found this to be quite useful, but need something that continues into 3.X. > > Rob -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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
> > 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. > > Just an implementation notes, doesn't change the fact that it can be > done and it's designed to be modifiable. This is only nitpicking about a side-topic, but: Just because it can be done does not mean that it was designed for that purpose. You argument is like saying that a wrench was designed to be used as a hammer (after all, you can hit a nail with it). If one were to follow that argument, it would be very hard *not* to design something for a given purpose. > > 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. If RPATH were *designed* to be modifiable, it would need provisions to account for arbitrary path lengths. One possible solution (not necessarily the best, or even a good one) would be to make RPATH a fixed-length field, part of which is a pointer to the next entry, if any. Regards, Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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] using source files in build directory
Hi,
For header files, that's quite a normal thing to do - you just need to add the
CMAKE_CURRENT_BINARY_DIR to your include directories.
For .cpp files, you can write your target so that it is referencing the source
file in the binary directory. I.e.:
configure_file(
${CMAKE_CURRENT_SOURCE_DIRECTORY}/file1.cpp.in
${CMAKE_CURRENT_BINARY_DIRECTORY}/file1.cpp COPYONLY)
add_executable( target1 ${CMAKE_CURRENT_BINARY_DIRECTORY}/file1.cpp)
Is that sufficient for your needs?
If you rather need a real wildcard way to override arbitrary source files,
then you're probably out of luck. You could still write a wrapper around
add_executable and add_library that inspects source directory and binary
directory, but that might not be worth the effort...
Johannes
On Thursday 22 October 2015 15:13:08 Srinath Vadlamani wrote:
> Hello All,
> I am aware of out-of-source builds. I want to add modified source files
> to the out of source build directory and have CMake use these modified
> files.
>
> Below is my example:
> $pwd
>
> $ls
> CmakeLists.txt CMake README src tests doc ...
> $mkdir build1
> $cd build1
> $cp ../src/file1.cpp .
> $
> $ccmake
> $make -j N
> $
>
> Now I want to make another build directory that houses a few other modified
> files:
>
> $cd
> $mkdir build2
> $cd build2
> $cp ../src/file1.cpp . && cp ../src/file2.cpp .
> $
> $ccmake
> $make -j N
> $ but file2 mods helped>
>
>
> . and so on. The point is that the build directory allowing for
> modified source files helps preserve executables and the dependent source
> files for code management. Some may now chime in with opinions on version
> control usage, but I'm trying to understand if it is possible to do what I
> described and is possible with Autotools.
>
> Thank you for your time,
> <>Srinath
>
> =
> Srinath Vadlamani
> =
>
> On Thu, Oct 22, 2015 at 3:02 PM, Gonzalo wrote:
> > El 21/10/15 a las 17:45, Srinath Vadlamani escribió:
> >
> > Hello All,
> >
> > Is it possible to have CMake use source files in some particular order
> >
> > that are placed in the out-of-source build directory? This is allows for
> > the convenience of having multiple builds in different build directories
> > due to a few file changes while preserving the files themselves?
> >
> > You are aware that you can do out of source builds, right?
> >
> > $ mkdir build-linux64
> > $ cd build-linux64
> > $ cmake .. # plus any options you want
> > $ make
> >
> > --
> > Gonzalo Garramuñoggarr...@gmail.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware 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] C++11 flag not being added
Hi, CXX_STANDARD is a target property, not a global one. You can either set CXX_STANDARD for every target that needs it, or set it globally by changing the default value. You can do the latter by setting the variable CMAKE_CXX_STANDARD before defining any target that depends on it: set(CMAKE_CXX_STANDARD 11) HTH, Johannes On Tuesday 13 October 2015 10:22:36 Matthew S Wallace wrote: > I have the following two lines in my CMakeLists.txt > > set_property(GLOBAL PROPERTY CXX_STANDARD 11) > set_property(GLOBAL PROPERTY CXX_STANDARD_REQUIRED) > > However when compiling some of my source files, the -std=c++11 flag is not > added. > > Just for good measure I added: > target_compile_features(my_target PRIVATE cxx_strong_enums) to the target > that was having the problem. > > Not sure if it matters, but in this case the compile error I’m getting is > complaining because I’m referencing a fully scoped enum. If I explicitly > include -std=c++11 in my compile flags, everything works. > > I’m thinking I’m probably just misunderstanding how CXX_STANDARD works, but > any help would be appreciated. > > -Matt -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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] General cross platform stating place
Hi, On Monday 07 September 2015 23:47:35 Aaron Gray wrote: > cmake_minimum_required(VERSION 2.6) Just as a side note: if you need to support cmake 2.6, that's fine. However, if you are starting a new project and do not *need* to limit yourself to cmake 2.6, develop for a cmake version that as new as can be supported by your target platforms. (Even if you chose the newest cmake it will get kind of old within the lifetime of your project *g*) > set(CMAKE_AR /usr/bin/ar CACHE FILEPATH "Archiver") Why do you set CMAKE_AR? > It runs fine on Windows with MSVC, seems to be failing on MSYS :- MSVC doesn't use CMAKE_AR, so there should be no problems here. MSYS obviously tries to use CMAKE_AR, which you set to the unlikely (on windows) path of /usr/bin/ar. Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 Monday 15 June 2015 22:43:41 you wrote: Just a last question: I assume that most find module scripts distributed with cmake are not using this feature at the moment, right? Sadly, no. After reading your explaination I looked at documentation for FindBoost and FindGTest which are both used in all my projects and they dont seem to provide import targets. Are there plans to update the cmake scripts distributed with CMake On the one hand, FindPackage modules are, as far as I'm aware, slowly being updated to use imported targets. On the other hand, quite a few packages are missing a maintainer[1]. If you are using a package and want it to provide imported targets, I think your best bet is to propose a patch for the module and get it into cmake. That said, its worth mentioning that FindPackage modules are only intended for legacy projects which do not provide a PackageConfig.cmake file. If you are writing a new project, especially if it's based on cmake, you should write a PackageConfig.cmake file instead [2]. or is it just assumed that projects willing to use importing targets will write them somewhere before using them? Creating imported targets on your own is not the way to go. Better file a bug report or write a patch to add the functionality and get that into cmake. IMO, until the official module provides imported targets, you're better off using the old way. Cheers, Johannes [1] http://www.cmake.org/Wiki/CMake:Module_Maintainers#List [2] http://www.cmake.org/Wiki/CMake/Tutorials#CMake_Packages -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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 Monday 15 June 2015 16:40:10 Klaim - Joël Lamotte wrote:
So far I didn't get what imported targets helps with, so I'm a bit lost on
the usefulness of namespaces
but I am sure that I am missing something.
Imported targets improve the handling of find_package stuff. In the old days,
the common pattern for using another library as dependency was as follows:
find_package(XXX)
include_directories( ${XXX_INCLUDE_DIR} )
add_definitions( ${XXX_DEFINITIONS} )
target_link_library(YourTarget ${XXX_LIBRARIES} )
Sometimes you don't need the add_definitions part, and sometimes the variable
names are a little bit different. Most of the time you inadvertedly add
definitions and include directories for other targets, too.
With imported targets, you can combine everything that's needed to use a
library into an imported target, making the above pattern simpler and less
error-prone:
find_package(XXX)
target_link_library(YourTarget XXX)
With more complex libraries, you often have different components, and that's
when namespaces come in handy:
find_package(XXX COMPONENTS Base Advanced)
target_link_library(YourTarget XXX::Base)
Find_package(YYY COMPONENTS Base)
target_link_library(YourOtherTarget XXX::Advanced YYY::Base)
Does this answer your question?
Cheers,
Johannes
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware 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?
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?highlight=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. Cheers, Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware 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] Check_include_file is supposed make a definition?
On Wednesday 10 June 2015 00:48:06 J Decker wrote: CHECK_INCLUDE_FILE(stdint.h HAVE_STDINT_H) is this supposed to create some sort of ADD_DEFINITION( -DHAVE_STDINT_H) ? No. if not what else do I have to do to make that work? IF(HAVE_STDINT_H) ADD_DEFINITION(HAVE_STDINT_H) ENDIF() If you want to do this always, you can write a wrapper function, of course... Cheers, Johannes -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
