[cmake-developers] [CMake 0012561]: 2.8.6 download links do not point at tarballs/packages/etc..
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12561 == Reported By:Cameron Smith Assigned To: == Project:CMake Issue ID: 12561 Category: Documentation Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-11-06 09:56 EST Last Modified: 2011-11-06 09:56 EST == Summary:2.8.6 download links do not point at tarballs/packages/etc.. Description: The 2.8.6 download links http://cmake.org/cmake/resources/software.html do not point at tarballs/packages/etc.. Steps to Reproduce: Visit http://cmake.org/cmake/resources/software.html click one of the 2.8.6 download links. For instance: http://www.cmake.org/files/v2.8/cmake-2.8.6.tar.gz == Issue History Date ModifiedUsername FieldChange == 2011-11-06 09:56 Cameron Smith New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Wednesday 02 November 2011, Stephen Kelly wrote: On 11/02/2011 06:32 PM, David Faure wrote: #include foo.moc #include moc_foo.cpp This would have generated twice the same moc file, I think. IMO this is really confusing. Well there is no reason to include both, unless you have Q_OBJECT in the .cpp file too:-) I'm sure I've seen this in several places in Qt code. Grepping I found one in qt48/src/scripttools/debugging/qscriptenginedebugger.cpp QT_END_NAMESPACE #include qscriptenginedebugger.moc #include moc_qscriptenginedebugger.cpp I had a look now too. Why do they include both files here ? Using qmake, the qscriptenginedebugger.moc is as far as I can see, for the moc from the cpp file, while moc_qscriptenginedebugger.cpp is for the moc from the header. Now, why is the moc_...cpp actually #included at all ? Isn't it enough to list the header in the qmake file, and it will be moced ? Also, in qmake/options.cpp I see the follow code: Option::cpp_moc_mod = ; Option::h_moc_mod = moc_; ... Option::cpp_moc_ext = .moc; Option::h_moc_ext = .cpp; which seems to say that the moc file for foo.cpp will be foo.moc, while the moc file for foo.h will be moc_foo.cpp (so it can be built as a standalone cpp file). Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] cmake automoc breaks kde
On Sunday 06 November 2011, Thiago Macieira wrote: On Sunday, 6 de November de 2011 18:42:42 Alexander Neundorf wrote: On Wednesday 02 November 2011, Stephen Kelly wrote: On 11/02/2011 06:32 PM, David Faure wrote: #include foo.moc #include moc_foo.cpp This would have generated twice the same moc file, I think. IMO this is really confusing. Well there is no reason to include both, unless you have Q_OBJECT in the .cpp file too:-) I'm sure I've seen this in several places in Qt code. Grepping I found one in qt48/src/scripttools/debugging/qscriptenginedebugger.cpp QT_END_NAMESPACE #include qscriptenginedebugger.moc #include moc_qscriptenginedebugger.cpp I had a look now too. Why do they include both files here ? Using qmake, the qscriptenginedebugger.moc is as far as I can see, for the moc from the cpp file, while moc_qscriptenginedebugger.cpp is for the moc from the header. Now, why is the moc_...cpp actually #included at all ? Why not? Isn't it enough to list the header in the qmake file, and it will be moced ? That is correct. That's what creates the moc_cpp file. If the file is #included by anything, it isn't added to the list of sources to be compiled. So compiling is a bit faster. Any other reasons/advantages ? Am I right that with qmake foo.moc is always generated from the cpp file, while moc_foo.cpp is always generated from the header file ? Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] target_include_directories branch in stage
Hi,
As discussed on the cmake user mailing list, I'm interesting in implementing
the feature of target specific and configuration specific include
directories.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/39090/focus=39114
I've pushed the target-include-directories branch to stage, which implements
the feature. I started out as prototyping, but I ended up implementing API
that I think makes sense. I have not merged it into next yet as it is not
certain if it should be in the next release. I'd prefer it to be though if
we can sort out the issues with what should be the target feature set.
David mentioned one issue is whether the include directories of a target
property should overwrite those of the directory property (added with the
command include_directories). Like others on the other thread, I would
expect the final list of includes to be determined by addition. For example:
project(foo)
include_directories(${bar_INCLUDES})
add_library(foo_lib ...)
target_include_directories(foo CONFIG_TYPE DEBUG debug_helper.h)
The target_include_directories command there shouldn't overwrite the
${bar_INCLUDES}. I can't think of any case where that would be wanted.
The implementation in my branch so far makes the following possible:
** Both ${bar_INCLUDES} and ${spam_INCLUDES} are used when building foo.
Only ${bar_INCLUDES} are available when building ham.
include_directories(${bar_INCLUDES})
add_library(foo ...)
target_include_directories(foo ${spam_INCLUDES})
add_library(ham ...)
** ${spam_INCLUDES} appear before ${bar_INCLUDES} when building foo.
include_directories(${bar_INCLUDES})
add_library(foo ...)
target_include_directories(foo BEFORE ${spam_INCLUDES})
** Includes appear in the order spam bar yam when building foo.
include_directories(${bar_INCLUDES})
add_library(foo ...)
target_include_directories(foo BEFORE ${spam_INCLUDES})
target_include_directories(foo ${yam_INCLUDES})
** Includes appear in the order spam par bar yam when building foo.
include_directories(${bar_INCLUDES})
include_directories(BEFORE ${par_INCLUDES})
add_library(foo ...)
target_include_directories(foo BEFORE ${spam_INCLUDES})
target_include_directories(foo ${yam_INCLUDES})
** ${yam_INCLUDES} are used when building foo in all configurations.
${spam_INCLUDES} are used only when CMAKE_BUILD_TYPE == Debug.
add_library(foo ...)
target_include_directories(foo CONFIG_TYPE DEBUG ${spam_INCLUDES})
target_include_directories(foo ${yam_INCLUDES})
** ${yam_INCLUDES} are used when building foo in all configurations.
${spam_INCLUDES} are used only when CMAKE_BUILD_TYPE == Debug,
and they appear before the ${yam_INCLUDES} (and the directory level
includes)
add_library(foo ...)
target_include_directories(foo BEFORE CONFIG_TYPE DEBUG ${spam_INCLUDES})
target_include_directories(foo ${yam_INCLUDES})
The only thing potentially missing is a way to insert includes BEFORE others
in the target include directories, but after the directory level includes. I
can't think of any reason to want that and not simply be able to move the
invokations of target_include_directories around. ie,
target_include_directories(foo ${spam_INCLUDES})
target_include_directories(foo ${yam_INCLUDES})
instead of
target_include_directories(foo ${yam_INCLUDES})
target_include_directories(foo ${spam_INCLUDES})
I imagine that in every case, the person writing those lines 'owns' foo, so
they can control the positions of those lines.
The bugs David listed in the other thread are:
- http://public.kitware.com/Bug/view.php?id=1968
* Partially solved by this branch. Bug also requests source level includes.
- http://public.kitware.com/Bug/view.php?id=6269
* Partially solved by this branch. Bug also requests config level
link_directories and link libraries
- http://public.kitware.com/Bug/view.php?id=6493
* Not affected by this branch as far as I see.
- http://public.kitware.com/Bug/view.php?id=8189
* Not affected by this branch as far as I see. Bug requests source-level
include directories.
Issues:
* I have only tried to implement this with the makefile generator and have
so far only tested it with Unix Makefiles. One of the bugs says XCode
can't do source-level includes. Can it do target-level includes? Would I
have to implement this for all generators before it would be considered for
acceptance?
* There's scope for refactoring the new code in my branch as well as
potentially refactoring with the cmIncludeDirectoriesCommand.
* There's scope for optimization.
* I haven't written any tests yet.
So before I merge this into next, I'm wondering if this feature can be
considered for inclusion in 2.8.7?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check
[cmake-developers] Should sucessive calls to find_package for one package succeed?
Hi,
Should successive calls to find_package succeed in general?
Eg
find_package(Grantlee COMPONENTS Templates)
find_package(Grantlee COMPONENTS TextDocument)
?
Currently if the target package uses Config files and
install(TARGETS ... EXPORT)
the convention is to use
include(${CMAKE_CURRENT_LIST_DIR}/GrantleeTargets.cmake)
in the config file. The problem is that that Targets file uses an unguarded
ADD_LIBRARY(grantlee_templates SHARED IMPORTED)
which cmake errors on:
add_library cannot create imported target grantlee_templates because
another target with the same name already exists.
The fix appears to be to wrap the call to add_library:
if (NOT TARGET grantlee_templates)
ADD_LIBRARY(grantlee_templates SHARED IMPORTED)
endif()
I can fix this if it is a bug.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
