Re: [cmake-developers] linked-usage-cleanup regressed automoc
Stephen Kelly wrote: > Alexander Neundorf wrote: > >> The patch only avoided that specific situation when it occured with >> automoc, but the same situation can also happen independent from automoc. > > Not really, the attached case can only crash because of the automoc > support built-in in cmake. Can you create a testcase which does not rely > on that feature? Oh, of course the obvious way is to simply comment out the automoc lines. That causes the same crash. -- 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] linked-usage-cleanup regressed automoc
Alexander Neundorf wrote: > The patch only avoided that specific situation when it occured with > automoc, but the same situation can also happen independent from automoc. Not really, the attached case can only crash because of the automoc support built-in in cmake. Can you create a testcase which does not rely on that feature? 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
Re: [cmake-developers] linked-usage-cleanup regressed automoc
Alexander Neundorf wrote:
> Unfortunately this patch creates bug (
> http://public.kitware.com/Bug/view.php?id=13999 ) and doesn't fix the
> actual problem, the crash is still there.
>
> Before this patch, void cmQtAutomoc::SetupAutomocTarget(cmTarget* target)
> returned early if no Qt was present, and nothing bad happened in this
> case.
I think the better solution is to return early from InitializeMocSourceFile
in that case. I implemented that as the fix-automoc-no-qt branch.
>
> With this patch, the _automoc.cpp file is added to every target.
> Probably this fixes the original problem because now the target
> "no_link_language" has a link language, due to its newly attached source
> file no_link_language_automoc.cpp.
> It then crashes:
>
> CMake Error: CMake can not determine linker language for
> target:no_link_language
Yes, the problem is that CMake errors at generate-time do not actually
abort. All bets are off after hitting an error like that. Some if() {
return; } code could be added, but I don't think that would improve the
situation. It could just be delaying the occurance of another segfault.
Can something be done about generate-time errors instead?
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
Re: [cmake-developers] linked-usage-cleanup regressed automoc
On Monday 11 March 2013, Alexander Neundorf wrote: > Hi, ... > (this is again the backtrace from the earlier, unmodified version). > I think instead of avoiding the case where the code crashes, it should not > crash. > > I pushed the branch AutomocFixWithoutQt to stage. > It mostly reverts the previous change. > Additionally it adds a test for the case that there is no Qt, and it adds > handling for the case that a target does not contain any C++ files (it now > does nothing). > > The crash can be also reproduced with the attached example, completely > without Qt and/or automoc. in case it's not clear: the attached example crashes cmake before the patch, with the patch, and also in the AutomocFixWithoutQt branch. The patch only avoided that specific situation when it occured with automoc, but the same situation can also happen independent from automoc. That's why I reverted the patch mostly in the AutomocFixWithoutQt branch. 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] linked-usage-cleanup regressed automoc
Hi, On Wednesday 20 February 2013, Stephen Kelly wrote: > Alexander Neundorf wrote: > > On Wednesday 20 February 2013, Stephen Kelly wrote: > >> Brad King wrote: > >> > Please fix and add this case to the tests. > >> > >> I've added fix-automoc-linker-language to stage. Alex, could you review > >> please? > > > > If I see it correctly, actually nothing is done to each target between > > the calls to InitializeMocSourceFile() and the following > > SetupAutomocTarget(). So instead of running two loops over the targets, > > shouldn't it be enough to add the source file to the target early on in > > SetupAutomocTarget(), e.g. before the call to AddUtilityCommand() ? > > I tried that too, but the problem is that if two different targets are > dependent, it seems that the link closure is calculated and cached for the > dependent target before it gets its source file set. > > There are a few ways to deal with that, but I went with this one. > > I'll merge it soon. Thanks for reviewing. Unfortunately this patch creates bug ( http://public.kitware.com/Bug/view.php?id=13999 ) and doesn't fix the actual problem, the crash is still there. Before this patch, void cmQtAutomoc::SetupAutomocTarget(cmTarget* target) returned early if no Qt was present, and nothing bad happened in this case. With this patch, the _automoc.cpp file is added to every target. Probably this fixes the original problem because now the target "no_link_language" has a link language, due to its newly attached source file no_link_language_automoc.cpp. It then crashes: CMake Error: CMake can not determine linker language for target:no_link_language Program received signal SIGSEGV, Segmentation fault. 0x082d55a3 in std::vector >::begin() const () (gdb) bt #0 0x082d55a3 in std::vector >::begin() const () #1 0x082cc76d in isLinkDependentProperty(cmTarget*, std::basic_string, std::allocator > const&, char const*, char const*) () #2 0x082cc98d in cmTarget::IsLinkInterfaceDependentBoolProperty(std::basic_string, std::allocator > const&, char const*) () #3 0x083d9b8c in TargetPropertyNode::Evaluate(std::vector, std::allocator >, std::allocator, std::allocator > > > const&, cmGeneratorExpressionContext*, GeneratorExpressionContent const*, cmGeneratorExpressionDAGChecker*) const () #4 0x083d6b53 in GeneratorExpressionContent::Evaluate(cmGeneratorExpressionContext*, cmGeneratorExpressionDAGChecker*) const () #5 0x083de544 in cmCompiledGeneratorExpression::Evaluate(cmMakefile*, char const*, bool, cmTarget*, cmTarget*, cmGeneratorExpressionDAGChecker*) const () #6 0x083de438 in cmCompiledGeneratorExpression::Evaluate(cmMakefile*, char const*, bool, cmTarget*, cmGeneratorExpressionDAGChecker*) const () #7 0x082c4cc1 in processIncludeDirectories(cmTarget*, std::vector > const&, std::vector, std::allocator >, std::allocator, std::allocator > > >&, std::set, std::allocator >, std::less, std::allocator > >, std::allocator, std::allocator > > >&, cmGeneratorExpressionDAGChecker*, char const*, bool) () #8 0x082c5895 in cmTarget::GetIncludeDirectories(char const*) () #9 0x083e0e86 in cmGeneratorTarget::GetIncludeDirectories(char const*) () #10 0x08413808 in cmLocalGenerator::GetIncludeDirectories(std::vector, std::allocator >, std::allocator, std::allocator > > >&, cmGeneratorTarget*, char const*, char const*, bool) () #11 0x0844b611 in cmQtAutomoc::SetupAutomocTarget(cmTarget*) () #12 0x083e66fe in cmGlobalGenerator::CreateAutomocTargets() () #13 0x083e5e7f in cmGlobalGenerator::Generate() () #14 0x083f8ffe in cmGlobalUnixMakefileGenerator3::Generate() () #15 0x082f0cbe in cmake::Generate() () #16 0x082f0b01 in cmake::Run(std::vector, std::allocator >, std::allocator, std::allocator > > > const&, bool) () #17 0x08257b41 in do_cmake(int, char**) () #18 0x08257099 in main () (gdb) (this is again the backtrace from the earlier, unmodified version). I think instead of avoiding the case where the code crashes, it should not crash. I pushed the branch AutomocFixWithoutQt to stage. It mostly reverts the previous change. Additionally it adds a test for the case that there is no Qt, and it adds handling for the case that a target does not contain any C++ files (it now does nothing). The crash can be also reproduced with the attached example, completely without Qt and/or automoc. If you want I can enter a ticket for that. Alex no_link_lang_crash.tar.gz Description: application/compressed-tar -- 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] Qt 4 and 5 on the same system - qmake binary name priority
On Mon, Mar 11, 2013 at 12:45 PM, Brad King wrote: > On 03/11/2013 12:34 PM, Clinton Stimpson wrote: >> I fixed a few bugs with that patch, and it is now merged with next. > > Great, thanks for taking care of this. > I verified that next finds the correct qmake for me too, thanks for getting this in for the next release! Marcus -- 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] Qt 4 and 5 on the same system - qmake binary name priority
On 03/11/2013 12:34 PM, Clinton Stimpson wrote: > I fixed a few bugs with that patch, and it is now merged with next. Great, thanks for taking care of this. -Brad -- 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] Qt 4 and 5 on the same system - qmake binary name priority
On Monday, March 11, 2013 10:05:48 AM Clinton Stimpson wrote: > On Monday, March 11, 2013 11:23:31 AM Brad King wrote: > > On 03/08/2013 02:52 PM, Clinton Stimpson wrote: > > > Its not as simple as changing the order. > > > If I have my own build of Qt4, and if FindQt4.cmake had this: > > > find_program(QT_QMAKE_EXECUTABLE NAMES qmake4 qmake-qt4 qmake-mac qmake > > > ...) and I try to use my build of Qt > > > CMAKE_PREFIX_PATH=/home/me/qt/qt-4.7.2 cmake ../ > > > It finds /usr/bin/qmake-qt4 instead, because it searched for qmake-qt4 > > > in > > > all possible paths before searching for qmake. > > > > > > Currently, I think we need to keep "qmake" first. > > > > FYI, you changed it to the current order here: > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61ad5242#patch1 > > > > but we used to have qmake last. I think it may have flip-flopped a > > few times before that too but I do not remember for sure. > > > > > The proposed patch does improve the situation by making a separate > > > find_program() call for each executable name. It also verifies the > > > results of each find_program(). > > > > Is the patch acceptable? Do you have an alternative? > > > > I'd like this to be worked out ASAP. > > > > We're planning 2.8.11-rc1 later this week. > > > > Thanks, > > -Brad > > The patch is not acceptable. It breaks FindQt4.cmake on my system. > I can look into this. I fixed a few bugs with that patch, and it is now merged with next. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] Qt 4 and 5 on the same system - qmake binary name priority
On Monday, March 11, 2013 11:23:31 AM Brad King wrote: > On 03/08/2013 02:52 PM, Clinton Stimpson wrote: > > Its not as simple as changing the order. > > If I have my own build of Qt4, and if FindQt4.cmake had this: > > find_program(QT_QMAKE_EXECUTABLE NAMES qmake4 qmake-qt4 qmake-mac qmake > > ...) and I try to use my build of Qt > > CMAKE_PREFIX_PATH=/home/me/qt/qt-4.7.2 cmake ../ > > It finds /usr/bin/qmake-qt4 instead, because it searched for qmake-qt4 in > > all possible paths before searching for qmake. > > > > Currently, I think we need to keep "qmake" first. > > FYI, you changed it to the current order here: > > http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61ad5242#patch1 > > but we used to have qmake last. I think it may have flip-flopped a > few times before that too but I do not remember for sure. > > > The proposed patch does improve the situation by making a separate > > find_program() call for each executable name. It also verifies the > > results of each find_program(). > > Is the patch acceptable? Do you have an alternative? > > I'd like this to be worked out ASAP. > > We're planning 2.8.11-rc1 later this week. > > Thanks, > -Brad The patch is not acceptable. It breaks FindQt4.cmake on my system. I can look into this. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] Qt 4 and 5 on the same system - qmake binary name priority
On 03/08/2013 02:52 PM, Clinton Stimpson wrote: > Its not as simple as changing the order. > If I have my own build of Qt4, and if FindQt4.cmake had this: > find_program(QT_QMAKE_EXECUTABLE NAMES qmake4 qmake-qt4 qmake-mac qmake ...) > and I try to use my build of Qt > CMAKE_PREFIX_PATH=/home/me/qt/qt-4.7.2 cmake ../ > It finds /usr/bin/qmake-qt4 instead, because it searched for qmake-qt4 in all > possible paths before searching for qmake. > > Currently, I think we need to keep "qmake" first. FYI, you changed it to the current order here: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=61ad5242#patch1 but we used to have qmake last. I think it may have flip-flopped a few times before that too but I do not remember for sure. > The proposed patch does improve the situation by making a separate > find_program() call for each executable name. It also verifies the results > of > each find_program(). Is the patch acceptable? Do you have an alternative? I'd like this to be worked out ASAP. We're planning 2.8.11-rc1 later this week. Thanks, -Brad -- 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] [CMake 0013999]: CMAKE_AUTOMOC ON without find_package(Qt*) does not build
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13999 == Reported By:Stephen Kelly Assigned To:Alex Neundorf == Project:CMake Issue ID: 13999 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: assigned == Date Submitted: 2013-03-11 08:30 EDT Last Modified: 2013-03-11 08:30 EDT == Summary:CMAKE_AUTOMOC ON without find_package(Qt*) does not build Description: Instead we get Scanning dependencies of target foo make[2]: *** No rule to make target `foo_automoc.cpp', needed by `CMakeFiles/foo.dir/foo_automoc.cpp.o'. Stop. It might make sense to report an error at cmake time. == Issue History Date ModifiedUsername FieldChange == 2013-03-11 08:30 Stephen Kelly New Issue 2013-03-11 08:30 Stephen Kelly Status new => assigned 2013-03-11 08:30 Stephen Kelly Assigned To => Alex Neundorf == -- 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
