Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake
On 2015-04-28 14:22-0400 Brad King wrote: On 04/27/2015 05:53 PM, Alan W. Irwin wrote: Anybody here got a clue about what is going on? Please strip it down to a minimal example. That will either find the culprit or provide a test case we can use independently. Hi Brad: The problem is I am reporting the problem second-hand, and I don't have access to a Cygwin platform myself. But from the report I received the incorrect warning message occurs each time a different compiler is enabled. So this is just an educated guess, but I think the following minimal two-line project (which enables the C compiler) cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR) project(test_cygwin C) would exercise the code in $PREFIX/share/cmake-3.2/Modules/Platform/CYGWIN.cmake and, it is that code that generates the incorrect warning message that my reporter is seeing. So please let me know if the above two-liner does provide that desired test case for the bug, i.e., always generates the warning on Cygwin platforms despite the above minimum CMake version. By the way, the above order of cmake_minimum_required and project commands is exactly the order used by PLplot if that order is relevant to this issue. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Le 28/04/15 12:23, Domen Vrankar a écrit : Hi, Sorry for not replying sooner. Please find attached a patch for the reworked documentation. I tried to make the doc more consistent with the CPackRPM (doc right after the variable declaration and options afterwards). I also put links for the variables and changed the formatting a bit. Thanks for the patches. You are doing a great work but please start splitting patches into subpatches... Each patch you provide is a combination of fixing one thing and adding a bunch of new things to it as well. Until one patch is added to master that patch is not finished and should not be built upon with new patches that are remotely related at best. If you intend to provide the patches like that then rework the patches yourself and resubmit all of them each time until they are applied. There are a couple of things though: - the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code I'll take a look after we finish with current patches... - right now, the CPACK_COMPONENT_COMP_DESCRIPTION is used as an equivalent to the CPACK_DEBIAN_PACKAGE_DESCRIPTION per component. If I follow the RPM conventions, those would be called CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION, which I find also better. However, in that case, should it default to CPACK_COMPONENT_COMP_DESCRIPTION or to CPACK_DEBIAN_PACKAGE_DESCRIPTION? In fact CPACK_COMPONENT_COMP_DESCRIPTION and CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION would have the same purpose and I think that it will not be obvious for the user to cope with all those variables. They would not have the same purpose - one is for setting value for all package generators at once while the other is for debian specific content. I am not a fan of generator specific overrides so I haven't bugged you with that entire hierarchy because it can be added later and because you volunteered for completely different functionality in the first place. On the other hand that is the preferred way of Brad and Eric so I intended to add the overrides later on. Regards, Domen Hi, I'll resubmit the patches then. Best, Raffi -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
Why are we making the restriction more restrictive than it needs to be? We only need this for multiple targets and not within a single target. This is how I see it. 1. Using MAIN DEPENDENCY is a useful and desirable feature of FindCUDA. 2. A single input file can be used multiple time to generate different output files (think .cu to .ptx). This currently works without errors or warnings. 3. We add this check, and now projects that previously built without warnings must either: 3.a. Disable useful feature of MAIN DEPENDENCY 3.b. Turn policy off - the user may not even realize why this was triggered in the first place because this code was generated by FindCUDA. 3.c. User will need to go through and manually filter out which files can't have MAIN DEPENDENCY. 3.d FindCUDA disables MAIN DEPENDENCY by default to the detriment of all users. Ideally what should happen is: 1. MAIN DEPENDENCY issues cross targets should automatically be downgraded to DEPENDENCY with a warning. 2. MAIN DEPENDENCY within a target works as before. This will have the greatest backward compatibility and be of the most use to users. I'm also curious why specifying MAIN DEPENDENCY in make file generators has any special effect since according the documentation there be no functional difference. It seems like this is more a bug in how MAIN DEPENDENCY is being handled. Using warnings and errors to correct this seems a bit like the wrong solution. On Tue, Apr 28, 2015 at 1:10 AM Nils Gladitz nilsglad...@gmail.com wrote: On 04/27/2015 11:48 PM, James Bigler wrote: The problem is the current detection only barfs (unless I missed something - please correct if I'm wrong). What we need is detection and adaptation. Rather than telling the user, DON'T DO THAT! we should be helping the user out by saying, I know you wanted this to be attached as a MAIN_DEPENDENCY, but that doesn't work, so I'm going to help you out and disable this feature for this file. Then I can specify MAIN_DEPENDENCY and not worry about the collisions that cause problems. Yes, I prefer the deterministic barfing that diagnoses documented restrictions over elusive build failures. I am not opposed to your change if your implementation guarantees that the aforementioned build failures don't creep through again. If I understand correctly you would still output a warning diagnostic when degrading duplicate MAIN_DEPENDENCY? Not sure I would like that. Most CMake diagnostics generally imply something that the project developer can fix ... which isn't feasible if you make the behavior part of the design in FindCUDA.cmake. On the other hand the user may himself use MAIN_DEPENDENCY outside the scope of FindCUDA.cmake in which case silent degrading isn't optimal either ... but I guess I could live with that. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015538]: set_property(SOURCE ) not working for MASM assembly files within Visual Studio 2014 generator
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=15538 == Reported By:Wolfgang Assigned To: == Project:CMake Issue ID: 15538 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-04-28 12:52 EDT Last Modified: 2015-04-28 12:52 EDT == Summary:set_property(SOURCE ) not working for MASM assembly files within Visual Studio 2014 generator Description: the generator now adds definitions and compiler flags to the masm command. Overwriting those parameters with SET_PROPERTY(SOURCE test.asm PROPERTY COMPILE_FLAGS my_asm_flags) and SET_PROPERTY(SOURCE test.asm PROPERTY COMPILE_DEFINITIONS my_definitions) is not respected == Issue History Date ModifiedUsername FieldChange == 2015-04-28 12:52 Wolfgang New Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?
Nils Gladitz wrote: On 04/28/2015 09:30 AM, Alan W. Irwin wrote: OK. Thanks, for pointing that out. Could you make that more obvious in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e. change the summary line from Disallow use of the LOCATION target property. == Disallow use of the LOCATION property for build targets. Thanks, I implemented your suggestion: http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=853ef717;hp=397b6298602f1496d1b946f5db827f5807d6ed23 Thanks Nils, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMAKE_TOOLCHAIN_FILE and ExternalProject_Add
Andrey Pokrovskiy wrote: Hi, I'm using cmake and CMAKE_TOOLCHAIN_FILE to build the project and it's dependencies. Some toolchain files have additional options (like API version, target architecture, linker type, etc.) which you need to pass to cmake command with -D in addition to the -DCMAKE_TOOLCHAIN_FILE= itself. There should be no need for that. With reference to what Brad wrote, you might find any of this interesting: http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/52129/focus=52142 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9729 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9578 Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake
On 04/28/2015 04:15 PM, Alan W. Irwin wrote:
The problem is I am reporting the problem second-hand, and I don't
have access to a Cygwin platform myself. But from the report I
received the incorrect warning message occurs each time a different
compiler is enabled.
The patch to plplot below removes most of the warnings for me.
-Brad
diff --git a/cmake/modules/language_support.cmake
b/cmake/modules/language_support.cmake
index 2cf5c95..333eb99 100644
--- a/cmake/modules/language_support.cmake
+++ b/cmake/modules/language_support.cmake
@@ -12,7 +12,8 @@ if(ENABLE_workaround_9220)
function(workaround_9220 language language_works)
#message(DEBUG: language = ${language})
set(text
- project(test C)
+ cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)
+project(test C)
# Locations where PLplot cmake build system first looks for cmake modules.
set(CMAKE_MODULE_PATH
${PROJECT_SOURCE_DIR}/cmake/modules
@@ -26,7 +27,6 @@ if(NOT CMAKE_PLATFORM_INFO_DIR)
message(STATUS 'CMAKE_PLATFORM_INFO_DIR = \${CMAKE_PLATFORM_INFO_DIR}')
endif(NOT CMAKE_PLATFORM_INFO_DIR)
-cmake_minimum_required(VERSION 3.0.2 FATAL_ERROR)
message(STATUS \CMAKE_GENERATOR = ${CMAKE_GENERATOR}\)
#enable_language(${language} OPTIONAL)
enable_language(${language})
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake
On 2015-04-28 16:44-0400 Brad King wrote: On 04/28/2015 04:15 PM, Alan W. Irwin wrote: The problem is I am reporting the problem second-hand, and I don't have access to a Cygwin platform myself. But from the report I received the incorrect warning message occurs each time a different compiler is enabled. The patch to plplot below removes most of the warnings for me. Hi Brad: That is a really interesting result. I notice your patch for PLplot simply makes sure that cmake_minimum_required(...) occurs before project(...) (for this part of PLplot). Just to confirm all of this in a simple way outside of PLplot, if the simple test I suggested has its two lines swapped so that project(...) occurs before cmake_minimum_required(...), does that also generate the spurious message on Cygwin? Assuming that simple confirmation of the required ordering of those two CMake commands (at least on the Cygwin platform if not others), I notice there is no mention of such ordering in the CMake documentation of cmake_minimum_required() and project(), and I hope you will be willing to fix that documentation issue with something like For best results it is highly recommended that the cmake_minimum_required command appear before the project command in the documentation of both commands. Also, a spurious warning is probably not that big a deal, but if you think the incorrect order of project(...) before cmake_minimum_required(...) could lead to more serious issues now or in the future as Platform code gets more and more complex, then I suggest you implement some code for one of those commands that enforces that order, subject, of course, to a policy so that you do not introduce backwards incompatibilities with this change. Since there are still some remaining spurious warnings on PLplot for you after you applied your patch, I took a look throughout our source code, and it turns out that misordering issue occurs a lot of different places (except for our top-level CMakeLists.txt which has the correct ordering). So I plan to address all of those ordering issues, and I hope that will eliminate all these spurious warnings for PLplot on Cygwin (and maybe make the PLplot build system more reliable on all platforms if potentially there are more serious issues if those two statements are misordered). Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?
On 04/28/2015 09:30 AM, Alan W. Irwin wrote: OK. Thanks, for pointing that out. Could you make that more obvious in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e. change the summary line from Disallow use of the LOCATION target property. == Disallow use of the LOCATION property for build targets. Thanks, I implemented your suggestion: http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=853ef717;hp=397b6298602f1496d1b946f5db827f5807d6ed23 Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generator Expressions in CPack (Module) variables
Hello Nils,
thank you for the pointers.
On 24/04/15 21:30, Nils Gladitz wrote:
On 24.04.2015 20:55, Gregor Jasny wrote:
Hello,
would it be possible to add generator expression support to CPack
so that I can use $CONFIG within CPACK_PACKAGE_FILE_NAME? I'm
using the CPack module from within my CMakeLists.txt.
I'm trying to generate unique file names per architecture and
configuration but multi config generators like Xcode make this
harder than expected.
You should be able to do this without generator expressions and just
CPACK_PROJECT_CONFIG_FILE [1] and CPACK_BUILD_CONFIG [2].
If you really do require/want generator expressions you should be able
to combine that with file(GENERATE) and include().
Unfortunately the CPACK_BUILD_CONFIG approach does only work for
multi-config generators. As far as I understand CPACK_BUILD_CONFIG gets
only set if the -C command line option was given to cpack. But this
option is only added conditionally and omitted for Makefile builds:
void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
...
if ( cmakeCfgIntDir *cmakeCfgIntDir cmakeCfgIntDir[0] != '.' )
{
singleLine.push_back(-C);
singleLine.push_back(cmakeCfgIntDir);
}
Now I'm just wondering if conditionally setting -C / CPACK_BUILD_CONFIG
is the right thing to do?
Thanks,
Gregor
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generator Expressions in CPack (Module) variables
On 04/28/2015 10:57 AM, Gregor Jasny wrote:
Unfortunately the CPACK_BUILD_CONFIG approach does only work for
multi-config generators. As far as I understand CPACK_BUILD_CONFIG gets
only set if the -C command line option was given to cpack. But this
option is only added conditionally and omitted for Makefile builds:
void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
...
if ( cmakeCfgIntDir *cmakeCfgIntDir cmakeCfgIntDir[0] != '.' )
{
singleLine.push_back(-C);
singleLine.push_back(cmakeCfgIntDir);
}
Now I'm just wondering if conditionally setting -C / CPACK_BUILD_CONFIG
is the right thing to do?
I don't know ... but as a local workaround you might be able to set
CPACK_BUILD_CONFIG before include(CPack) conditionally when using
single-configuration generators.
Assuming nothing else messes with CMAKE_BUILD_TYPE when using
multi-configuration generators e.g.:
if(CMAKE_BUILD_TYPE)
set(CPACK_BUILD_TYPE ${CMAKE_BUILD_TYPE})
endif()
include(CPack)
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?
Hi Nils: Thanks for your quick reply. More below in context. On 2015-04-28 08:45+0200 Nils Gladitz wrote: On 04/28/2015 08:00 AM, Alan W. Irwin wrote: The Qt5 cmake documentation at http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me to before states you should use the LOCATION property of targets to determine the actual path to libraries. The PLplot build system requires those locations so it can transform them into the -L and -l form required to generate its pkg_config *.pc files. Some time ago I got this process to work fine for CMP0026 OLD and Qt5, but what is the alternative I should use for the CMP0026 NEW case (which disallows using the LOCATION property for targets)? Note PLplot uses a minimum CMake version of 3.0.2 so I am looking for a CMP0026 NEW solution that works for that version or above for Qt5. CMP0026 only applies to build targets. The location of build targets is still in flux during configuration which is why getting the location of those during configuration time is unsafe. For imported targets this does not apply since their location is fixed. OK. Thanks, for pointing that out. Could you make that more obvious in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e. change the summary line from Disallow use of the LOCATION target property. == Disallow use of the LOCATION property for build targets. I took that summary line to mean exactly what it said and just plain missed the reference to build targets that is in the first paragraph of that documenation. For which configuration LOCATION returns isn't defined but I suppose that may not matter for pkg-config. Otherwise you may want to look into LOCATION_CONFIG. I don't understand exactly what you mean by configuration LOCATION returns. From what you said that term means something different from LOCATION_CONFIG and in any case is not relevant to my use case of generating pkg-config *.pc files with our build system, but I am nevertheless curious about what you meant.) Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?
On 04/28/2015 09:30 AM, Alan W. Irwin wrote: I don't understand exactly what you mean by configuration LOCATION returns. From what you said that term means something different from LOCATION_CONFIG and in any case is not relevant to my use case of generating pkg-config *.pc files with our build system, but I am nevertheless curious about what you meant.) E.g. on windows with MSVC cmake target exports may refer to locations of both a Debug and a Release binary. LOCATION returns the path to one of those two (you don't know which). LOCATION_DEBUG and LOCATION_RELEASE would refer to the Debug and Release binary respectively. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generator Expressions in CPack (Module) variables
2015-04-28 10:57 GMT+02:00 Gregor Jasny gja...@googlemail.com:
Hello Nils,
thank you for the pointers.
On 24/04/15 21:30, Nils Gladitz wrote:
On 24.04.2015 20:55, Gregor Jasny wrote:
Hello,
would it be possible to add generator expression support to CPack
so that I can use $CONFIG within CPACK_PACKAGE_FILE_NAME? I'm
using the CPack module from within my CMakeLists.txt.
From my understanding $CONFIG is a build time value.
evaluating $CONFIG at CPack time may be hard because
one can simply call:
cpack -G generator
then CONFIG definition is implicit and only known when the build tool is
called...
I'm trying to generate unique file names per architecture and
configuration but multi config generators like Xcode make this
harder than expected.
You should be able to do this without generator expressions and just
CPACK_PROJECT_CONFIG_FILE [1] and CPACK_BUILD_CONFIG [2].
If you really do require/want generator expressions you should be able
to combine that with file(GENERATE) and include().
Unfortunately the CPACK_BUILD_CONFIG approach does only work for
multi-config generators. As far as I understand CPACK_BUILD_CONFIG gets
only set if the -C command line option was given to cpack. But this option
is only added conditionally and omitted for Makefile builds:
void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
...
if ( cmakeCfgIntDir *cmakeCfgIntDir cmakeCfgIntDir[0] != '.' )
{
singleLine.push_back(-C);
singleLine.push_back(cmakeCfgIntDir);
}
Now I'm just wondering if conditionally setting -C / CPACK_BUILD_CONFIG is
the right thing to do?
If it is possible to always define it may be it could be done.
Beware of backward compatibility issue though.
--
Eric
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Probable bug in message output from Modules/Platform/CYGWIN.cmake
On 04/27/2015 05:53 PM, Alan W. Irwin wrote: Anybody here got a clue about what is going on? Please strip it down to a minimal example. That will either find the culprit or provide a test case we can use independently. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Is there a way to avoid LOCATION property with Qt5?
The Qt5 cmake documentation at http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me to before states you should use the LOCATION property of targets to determine the actual path to libraries. The PLplot build system requires those locations so it can transform them into the -L and -l form required to generate its pkg_config *.pc files. Some time ago I got this process to work fine for CMP0026 OLD and Qt5, but what is the alternative I should use for the CMP0026 NEW case (which disallows using the LOCATION property for targets)? Note PLplot uses a minimum CMake version of 3.0.2 so I am looking for a CMP0026 NEW solution that works for that version or above for Qt5. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?
On 04/28/2015 08:00 AM, Alan W. Irwin wrote: The Qt5 cmake documentation at http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me to before states you should use the LOCATION property of targets to determine the actual path to libraries. The PLplot build system requires those locations so it can transform them into the -L and -l form required to generate its pkg_config *.pc files. Some time ago I got this process to work fine for CMP0026 OLD and Qt5, but what is the alternative I should use for the CMP0026 NEW case (which disallows using the LOCATION property for targets)? Note PLplot uses a minimum CMake version of 3.0.2 so I am looking for a CMP0026 NEW solution that works for that version or above for Qt5. CMP0026 only applies to build targets. The location of build targets is still in flux during configuration which is why getting the location of those during configuration time is unsafe. For imported targets this does not apply since their location is fixed. For which configuration LOCATION returns isn't defined but I suppose that may not matter for pkg-config. Otherwise you may want to look into LOCATION_CONFIG. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY
On 04/27/2015 11:48 PM, James Bigler wrote: The problem is the current detection only barfs (unless I missed something - please correct if I'm wrong). What we need is detection and adaptation. Rather than telling the user, DON'T DO THAT! we should be helping the user out by saying, I know you wanted this to be attached as a MAIN_DEPENDENCY, but that doesn't work, so I'm going to help you out and disable this feature for this file. Then I can specify MAIN_DEPENDENCY and not worry about the collisions that cause problems. Yes, I prefer the deterministic barfing that diagnoses documented restrictions over elusive build failures. I am not opposed to your change if your implementation guarantees that the aforementioned build failures don't creep through again. If I understand correctly you would still output a warning diagnostic when degrading duplicate MAIN_DEPENDENCY? Not sure I would like that. Most CMake diagnostics generally imply something that the project developer can fix ... which isn't feasible if you make the behavior part of the design in FindCUDA.cmake. On the other hand the user may himself use MAIN_DEPENDENCY outside the scope of FindCUDA.cmake in which case silent degrading isn't optimal either ... but I guess I could live with that. Nils -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Hi, Sorry for not replying sooner. Please find attached a patch for the reworked documentation. I tried to make the doc more consistent with the CPackRPM (doc right after the variable declaration and options afterwards). I also put links for the variables and changed the formatting a bit. Thanks for the patches. You are doing a great work but please start splitting patches into subpatches... Each patch you provide is a combination of fixing one thing and adding a bunch of new things to it as well. Until one patch is added to master that patch is not finished and should not be built upon with new patches that are remotely related at best. If you intend to provide the patches like that then rework the patches yourself and resubmit all of them each time until they are applied. There are a couple of things though: - the variable CPACK_PACKAGE_CONTACT does not exist anywhere in the code I'll take a look after we finish with current patches... - right now, the CPACK_COMPONENT_COMP_DESCRIPTION is used as an equivalent to the CPACK_DEBIAN_PACKAGE_DESCRIPTION per component. If I follow the RPM conventions, those would be called CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION, which I find also better. However, in that case, should it default to CPACK_COMPONENT_COMP_DESCRIPTION or to CPACK_DEBIAN_PACKAGE_DESCRIPTION? In fact CPACK_COMPONENT_COMP_DESCRIPTION and CPACK_DEBIAN_COMP_PACKAGE_DESCRIPTION would have the same purpose and I think that it will not be obvious for the user to cope with all those variables. They would not have the same purpose - one is for setting value for all package generators at once while the other is for debian specific content. I am not a fan of generator specific overrides so I haven't bugged you with that entire hierarchy because it can be added later and because you volunteered for completely different functionality in the first place. On the other hand that is the preferred way of Brad and Eric so I intended to add the overrides later on. Regards, Domen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
I am having a look now at the changes you made on the first patch (say
75b0e1679c39ca824a4c49d9e1a2ae2b5f04ae06), file
RunCPackComponentsDEB/RunCPackVerifyResult-components-lintian-dpkgdeb-checks.cmake
Instead of finding lintian and dpkg-deb in the check file
find_program(LINTIAN_EXECUTABLE lintian)
find_program(DPKGDEB_EXECUTABLE dpkg-deb)
why not returning the string NOTFOUND in eg. the functions run_lintian
lintian_output, like this:
set(${lintian_output} NOTFOUND PARENT_SCOPE)
One reason is that tests that don't have prerequisites met should not
even be executed in the first place.
The other reason is that if I had time I would rewrite and generalize
all CPack tests to meet those expectations.
Regards,
Domen
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake 0011944]: CPackDeb: Support dependencies between components/Debian packages
Hi, Would you please add set( CPACK_DEBIAN_PACKAGE_DEBUG ON) to the file MyLibCPackConfig-splitted-components-depend2.cmake.in so that we also have the debug logs? I currently don't have access to my computer so I'll send you that in about a week. BTW, I do not know what CPackDEB.cmake you are running. Is it pushed somehow? I was using master git branch with all your patches applied so it's the same code you have. I just remembered that I did an incremental build an not a fresh one so I'll have to test if it makes a difference after I get back. Regards, Domen -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?
many places that you would use LOCATION you can use generator expressions http://www.cmake.org/cmake/help/v3.0/manual/cmake-generator-expressions.7.html $TARGET_FILE_DIR:targetname On Tue, Apr 28, 2015 at 12:30 AM, Alan W. Irwin ir...@beluga.phys.uvic.ca wrote: Hi Nils: Thanks for your quick reply. More below in context. On 2015-04-28 08:45+0200 Nils Gladitz wrote: On 04/28/2015 08:00 AM, Alan W. Irwin wrote: The Qt5 cmake documentation at http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me to before states you should use the LOCATION property of targets to determine the actual path to libraries. The PLplot build system requires those locations so it can transform them into the -L and -l form required to generate its pkg_config *.pc files. Some time ago I got this process to work fine for CMP0026 OLD and Qt5, but what is the alternative I should use for the CMP0026 NEW case (which disallows using the LOCATION property for targets)? Note PLplot uses a minimum CMake version of 3.0.2 so I am looking for a CMP0026 NEW solution that works for that version or above for Qt5. CMP0026 only applies to build targets. The location of build targets is still in flux during configuration which is why getting the location of those during configuration time is unsafe. For imported targets this does not apply since their location is fixed. OK. Thanks, for pointing that out. Could you make that more obvious in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e. change the summary line from Disallow use of the LOCATION target property. == Disallow use of the LOCATION property for build targets. I took that summary line to mean exactly what it said and just plain missed the reference to build targets that is in the first paragraph of that documenation. For which configuration LOCATION returns isn't defined but I suppose that may not matter for pkg-config. Otherwise you may want to look into LOCATION_CONFIG. I don't understand exactly what you mean by configuration LOCATION returns. From what you said that term means something different from LOCATION_CONFIG and in any case is not relevant to my use case of generating pkg-config *.pc files with our build system, but I am nevertheless curious about what you meant.) Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] Identify used source files
If someone is interessted in this solution:
set(FilenameUsedFiles ${CMAKE_BINARY_DIR}/UsedFiles.lst)
file(WRITE ${FilenameUsedFiles} )
function (parseArguments)
set(options)
set(oneValueArgs)
set(multiValueArgs)
cmake_parse_arguments(CFG ${options}${oneValueArgs}
${multiValueArgs}${ARGN} )
foreach(file ${ARGN})
get_filename_component(tempPath ${file} DIRECTORY)
string(FIND ${file} ${CMAKE_BINARY_DIR}buildPathFoundPos)
string(FIND ${file} ${CMAKE_SOURCE_DIR}sourcePathFoundPos)
if ((NOT ${file} STREQUALIMPORTED) AND
(NOT ${file} STREQUAL MODULE)AND
(NOT ${file} STREQUAL STATIC)AND
(NOT ${file} STREQUAL SHARED)AND
(NOT ${file} STREQUAL WIN32)AND
${buildPathFoundPos} EQUAL -1)
if (${sourcePathFoundPos} EQUAL -1)
file(APPEND ${FilenameUsedFiles}
${CMAKE_CURRENT_SOURCE_DIR}/${file}\n)
else()
file(APPEND ${FilenameUsedFiles} ${file}\n)
endif()
endif()
endforeach()
endfunction(parseArguments)
function(add_library name)
parseArguments(${ARGN})
_add_library(${name} ${ARGN})
endfunction()
function(add_executable name)
parseArguments(${ARGN})
_add_executable(${name} ${ARGN})
endfunction()
Best Regards
Roman
Am 28.04.2015 um 07:00 schrieb Roman Wüger roman.wue...@gmx.at:
Hello,
is there a proper solution to get all used source files for all defined
librarys and executables?
My first idea was to overload the main functions such as add_executable() and
add_library() temporarily in the main CMakeLists.txt and write a text file or
whatever, but I thought there were a better way.
Did anybody know a better way?
Maybe CMake has a way to get a list of used files?
The reason is to clean a big old source tree.
Thanks in advance
Best regards
Roman
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
