[cmake-developers] [CMake 0014818]: Out-of-source build does not work if an 'in-source' CMakeCache.txt file is available
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14818 == Reported By:Daniel Hasemann Assigned To: == Project:CMake Issue ID: 14818 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2014-03-20 03:28 EDT Last Modified: 2014-03-20 03:28 EDT == Summary:Out-of-source build does not work if an 'in-source' CMakeCache.txt file is available Description: I had the following problem: My CMake builds are in-source-builds at the moment and I am refactoring it to out-of-source builds. Because of old 'in-source' CMakeCache file, the out-of-source build does not work as long as this is available. IMHO the out-of-source build must not depend on in-source CMakeCache.txt Steps to Reproduce: cd src ls # foo.c bar.c CMakeCache.txt CMakeLists.txt build/ [...] rm -rf build mkdir build cd build cmake .. nothing does happen because of ../CMakeCache.txt == Issue History Date ModifiedUsername FieldChange == 2014-03-20 03:28 Daniel HasemannNew 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/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Generator rule parameters question
Hi, Watcom linker need pass resource files (.res) as extra item. Is it possible to get in generator rules separated list of resource files (.res) and separate list of object files (.obj/.o)? Jiri -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014819]: excluding ARCHIVE part of library target from install
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14819
==
Reported By:Richard Ulrich
Assigned To:
==
Project:CMake
Issue ID: 14819
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2014-03-20 04:44 EDT
Last Modified: 2014-03-20 04:44 EDT
==
Summary:excluding ARCHIVE part of library target from
install
Description:
When building shared libraries on windows, I can specify the install location
for the dll and lib file like this:
INSTALL(TARGETS MyLib
RUNTIME DESTINATION bin # - dll
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib # - lib
COMPONENT base
)
Now I should exclude the lib files from the generated installer.
As long as we used an external installer builder that I invoked with
ADD_CUSTOM_TARGET(), I just executed an ADD_CUSTOM_COMMAND() just before, that
deleted the lib files from the install directory.
But now that we use cpack to generate the installer, there is no suc
interception point anymore.
So the next thing I tried was what I found in
http://stackoverflow.com/questions/8636479/postpone-making-custom-target-until-install
:
INSTALL(CODE EXECUTE_PROCESS(
COMMAND del /F /Q ${TEMP2_CMAKE_INSTALL_PREFIX}bin*.lib
))
But that doesn't work, as it is executed too early.
I also searched if there are cpack options to exclude certain files, but the
only thing I found were filters for source files, but nothing for target files.
Anyway, I think the option to exclude the import libraries from target installs
should exist without such hacks.
==
Issue History
Date ModifiedUsername FieldChange
==
2014-03-20 04:44 Richard Ulrich 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] TARGET_OBJECTS and buildsystem replacement macros
Brad King wrote:
On 03/19/2014 01:41 PM, Stephen Kelly wrote:
However, should the macro remain when generating the buildsystem files?
If the place in those files where the values get written is per-config
then they can be replaced with the literal config names. Otherwise the
macros must be left so that the build system can substitute the config
name at build time.
Exactly. I don't have the information to determine that.
This is necessary for universal binary builds because the architecture
is substituted at build time by Xcode.
This seems to be the remaining unknowable, right?
Yes. When not building universal binaries we can probably hard-code
the one architecture to be built instead of using the placeholder.
When building universal binaries with Xcode anything that the project
does with the value of the generator expression will have to be aware
of multiple architectures anyway so perhaps we can just leave the
placeholder and let them deal with it.
I was thinking of something like this:
add_library(objlib OBJECT foo.cpp)
macro(install_objlib_hack)
foreach(lib ${ARGN})
set(dest objects)
install(FILES $TARGET_OBJECTS:${lib} DESTINATION ${dest})
file(GENERATE OUTPUT ${lib}Target.cmake
CONTENT
add_library(Prefix::${lib} INTERFACE IMPORTED)
set(objects \$TARGET_OBJECTS:${lib}\)
foreach(obj \${objects})
get_filename_component(objname \${obj} NAME)
list(APPEND srcs \\${IMPORT_PREFIX}/${dest}/\${objname}\)
endforeach()
set_property(TARGET Prefix::${lib} PROPERTY
INTERFACE_SOURCES \\${srcs}\)
)
endforeach()
endmacro()
install_objlib_hack(objlib)
It would be better with $EACH and $REPLACE expressions, but we can
ignore that for now.
If only the buildsystem tool knows the correct arch, does that mean that
CMake can not learn a built-in feature for installing object libraries,
because it is not possible to implement install() correctly for the files
for Xcode?
The immediate question is what to do about the the target-sources-refactor
topic I've re-merged to next.
1) I can modify the TargetObjectsNode to replace the CfgIntDir macros with
the actual configuration, but that will affect the generated buildsystem
files too
2) We can leave things as they are in the branch, meaning install(FILES)
won't work well with $TARGET_OBJECTS and let users of file(GENERATE) deal
with the output.
3) We can make it an error to use $TARGET_OBJECTS in any user-context of
generator expressions. That will also affect the use of
$TARGET_PROPERTY:SOURCES when object libraries are involved.
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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generator rule parameters question
On 03/20/2014 04:44 AM, Jiri Malak wrote: Watcom linker need pass resource files (.res) as extra item. Is it possible to get in generator rules separated list of resource files (.res) and separate list of object files (.obj/.o)? I don't think we do any explicit classification of .res files currently. The cmLocalGenerator::ExpandRuleVariable method would have to be taught a new RESOURCE_FILES placeholder. The generators that call ExpandRuleVariables will have to populate the placeholder value accordingly. -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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] TARGET_OBJECTS and buildsystem replacement macros
On 03/20/2014 05:52 AM, Stephen Kelly wrote: Brad King wrote: If the place in those files where the values get written is per-config then they can be replaced with the literal config names. Otherwise the macros must be left so that the build system can substitute the config name at build time. Exactly. I don't have the information to determine that. Perhaps the generators that need per-config values can use $CONFIG. Then in the contexts where the configuration is known during evaluation it can be replaced with the real config. In contexts where the configuration is not known but the evaluation is for the build system then the placeholder can be substituted for $CONFIG instead. If only the buildsystem tool knows the correct arch, does that mean that CMake can not learn a built-in feature for installing object libraries, because it is not possible to implement install() correctly for the files for Xcode? I'd rather have a builtin feature for installing object libraries than encourage use of the install_objlib_hack approach you posted. When generating install rules CMake knows about the OSX_ARCHITECTURES target property and could do something with the arch macros. The installed objects would have to be laid out such that an the target exports file could adjust the list of objects for an importing project based on the target architecture(s) enabled. 1) I can modify the TargetObjectsNode to replace the CfgIntDir macros with the actual configuration, but that will affect the generated buildsystem files too 2) We can leave things as they are in the branch, meaning install(FILES) won't work well with $TARGET_OBJECTS and let users of file(GENERATE) deal with the output. Does my $CONFIG suggestion above resolve this? I think it leaves only the Xcode $(CURRENT_ARCH) problem. Perhaps a similar $ARCH genex can be used for that too. 3) We can make it an error to use $TARGET_OBJECTS in any user-context of generator expressions. That will also affect the use of $TARGET_PROPERTY:SOURCES when object libraries are involved. This approach would allow us to delay a decision until later so let's use it if we can't find a good solution now. -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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [patch] treat .m files as c, not c++
On 03/19/2014 03:58 PM, Brad King wrote: I'll look at integrating the change. I've applied the patch here: Treat .m files consistently as C across all generators http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=95cdf132 with more detail in the commit message. 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] TARGET_OBJECTS and buildsystem replacement macros
Brad King wrote: If only the buildsystem tool knows the correct arch, does that mean that CMake can not learn a built-in feature for installing object libraries, because it is not possible to implement install() correctly for the files for Xcode? I'd rather have a builtin feature for installing object libraries than encourage use of the install_objlib_hack approach you posted. Me too. I just posted it to illustrate the problem and to point out that the problem may block the 'install object libraries' feature, until perhaps install() is updated to handle this problem. 1) I can modify the TargetObjectsNode to replace the CfgIntDir macros with the actual configuration, but that will affect the generated buildsystem files too 2) We can leave things as they are in the branch, meaning install(FILES) won't work well with $TARGET_OBJECTS and let users of file(GENERATE) deal with the output. Does my $CONFIG suggestion above resolve this? Perhaps. I think it leaves only the Xcode $(CURRENT_ARCH) problem. Perhaps a similar $ARCH genex can be used for that too. Perhaps. I'll not take that on now. 3) We can make it an error to use $TARGET_OBJECTS in any user-context of generator expressions. That will also affect the use of $TARGET_PROPERTY:SOURCES when object libraries are involved. This approach would allow us to delay a decision until later so let's use it if we can't find a good solution now. Ok. I've added a commit which implements this and which can be reverted in the future. 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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [patch] treat .m files as c, not c++
Took me a bit longer than I expected, but you can find the 'objective-c-support' topic at: https://github.com/swwilso1/CMake.git On Mar 19, 2014, at 11:55 AM, Steve Wilson ste...@wolfram.com wrote: On Mar 19, 2014, at 11:09 AM, Brad King brad.k...@kitware.com wrote: On 03/19/2014 12:50 PM, Tim Blechmann wrote: obj-c is a superset of c, while obj-c++ is a superset of obj-c this patch corrects this behavior. The incorrect behavior is left from the earliest days of CMake. Fixing this outright will change existing build behavior. We would have to do this with a CMake Policy. However, Steve Wilson is working on first-class Objective C and Objective C++ support: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/9371 That will resolve this in a compatible way by allowing projects to enable OBJC and/or OBJCXX languages to get .m and .mm sources compiled properly. Steve, do you have the work-in-progress topic published somewhere? Not at the moment, but I’ll work on making the topic available on github before the end of the day. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers signature.asc Description: Message signed with OpenPGP using GPGMail -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [patch] treat .m files as c, not c++
On 03/20/2014 11:38 AM, Steve Wilson wrote: Took me a bit longer than I expected, but you can find the 'objective-c-support' topic at: https://github.com/swwilso1/CMake.git Great, thanks. I encourage others to look at the topic and the discussion thread I linked earlier in this thread. -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/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [patch] treat .m files as c, not c++
I'll look at integrating the change. I've applied the patch here: Treat .m files consistently as C across all generators http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=95cdf132 with more detail in the commit message. thanks a lot! tim -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
