Re: [cmake-developers] linked-usage-cleanup regressed automoc
On 03/12/2013 06:08 PM, Alexander Neundorf wrote: >> The original use case in this thread has a header-only target whose >> C++ linker language comes from the automoc source. This preserves >> that functionality too. > > I'm not sure this is "functionality", and not actually a bug, see below. It worked in 2.8.10. I've seen a project use it. >> I've rebased Alex's AutomocFixWithoutQt topic on those changes >> for reference. > > thanks, I'll have a closer look at this tomorrow (or Thursday). 2.8.11-rc1 is coming up on Thursday if the dashboard is clean tonight. A whole day went by without discussion or progress on this so I took matters into my own hands since it is a regression. > My AutomocFixWithoutQt branch basically reverts the first commit, so automoc > is now again only one step, without the temporary vector of targets, without > needing additional checks. In this form the case that Qt was not present was > already handled correctly. > So with your fix and without Stephens first commit (79568f95) everything > would > have been fine already. ...except that the test case added by his patch then fails. The test case covers exactly the header-only case. I actually did this approach first. That's why I rebased and cleaned up your topic. Then I found the remaining test failure and switched to Stephen's approach. > So my first patch in the branch basically reverts 79568f95. Yes, I cleaned up the commit message to explain what is actually reverted and what is not. However, see the discussion of GetIncludeDirectories: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=79568f95 I think the two steps are needed to make that work. Stephen? > The second patch in my branch actually fixes a slightly different error (?) > case, which was not handled yet, and which is also not handled in the fix- > automoc-no-qt branch. > If you set CMAKE_AUTOMOC to ON, and Qt is available, and there are some plain > C targets, those turn into C++ too, since the automoc cpp file is added to > them. Nobody complained about this yet, but I think that's a bug. > Also I think turning a header-only C or C++ (?) library via automoc into a > "normal" C++ library, which you actually have to link against, is strange, if > not a bug. We'll need a policy to change this since it worked in 2.8.10. It's not a regression so I'm not going to rush that for 2.8.11. One can always set the AUTOMOC property explicitly to turn it off. -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] linked-usage-cleanup regressed automoc
On Tuesday 12 March 2013, Brad King wrote:
> On 03/11/2013 06:54 PM, Stephen Kelly wrote:
> > 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.
>
> Yes, that preserves the GetIncludeDirectories part mentioned in the
> original commit 79568f95.
>
> The original use case in this thread has a header-only target whose
> C++ linker language comes from the automoc source. This preserves
> that functionality too.
I'm not sure this is "functionality", and not actually a bug, see below.
> > 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?
>
> Lots of generation APIs exit early and tolerate missing info.
> Without C++ exceptions and proper RAII we will not be able to
> have a general solution.
>
> Every use of GetLinkInformation should return early if it is NULL.
> See the patches linked in my previous response to this thread.
>
> I've rebased Alex's AutomocFixWithoutQt topic on those changes
> for reference. However, your fix-automoc-no-qt is the correct
> solution IMO. I've rebased that too and merged to next.
thanks, I'll have a closer look at this tomorrow (or Thursday).
If I understand correctly, Stephens first commit (79568f95) split automoc into
two steps.
In the first step, a header-only no-link-language library was turned into a
normal C++ library by adding the automoc C++ source file to it.
This way the crash-case was avoided.
The fix-automoc-no-qt now adds more logic to that two-step process to handle
the case that Qt is not present.
My AutomocFixWithoutQt branch basically reverts the first commit, so automoc
is now again only one step, without the temporary vector of targets, without
needing additional checks. In this form the case that Qt was not present was
already handled correctly.
So with your fix and without Stephens first commit (79568f95) everything would
have been fine already.
So my first patch in the branch basically reverts 79568f95.
The second patch in my branch actually fixes a slightly different error (?)
case, which was not handled yet, and which is also not handled in the fix-
automoc-no-qt branch.
If you set CMAKE_AUTOMOC to ON, and Qt is available, and there are some plain
C targets, those turn into C++ too, since the automoc cpp file is added to
them. Nobody complained about this yet, but I think that's a bug.
Also I think turning a header-only C or C++ (?) library via automoc into a
"normal" C++ library, which you actually have to link against, is strange, if
not a bug.
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
On 03/11/2013 06:54 PM, Stephen Kelly wrote:
> 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.
Yes, that preserves the GetIncludeDirectories part mentioned in the
original commit 79568f95.
The original use case in this thread has a header-only target whose
C++ linker language comes from the automoc source. This preserves
that functionality too.
> 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?
Lots of generation APIs exit early and tolerate missing info.
Without C++ exceptions and proper RAII we will not be able to
have a general solution.
Every use of GetLinkInformation should return early if it is NULL.
See the patches linked in my previous response to this thread.
I've rebased Alex's AutomocFixWithoutQt topic on those changes
for reference. However, your fix-automoc-no-qt is the correct
solution IMO. I've rebased that too and merged to next.
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
Re: [cmake-developers] linked-usage-cleanup regressed automoc
On 03/11/2013 07:01 PM, Stephen Kelly wrote: > 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. Fixed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=92a2ab70 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab079ee6 but please review these changes. 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
Re: [cmake-developers] Modules/Compiler: TI DSP/ARM
On Tue, Mar 12, 2013 at 7:43 PM, Alexander Neundorf wrote: > oh, this is working for you too ? > Cool :-) > I have not tried yet, but I know both toolchains now. They use the same interface. They only have different backend implementations as far as I can tell. > Do you know for which other processors TI has a similar toolchain ? > Simply naming it "TI" is quite general, so I'd like to be sure. > As far as I know there are also the PRU assembler and loader, but that can be called toolchain only in a limited sense. For instance, TI does not plan [1] to provide a C compiler for that due to the overhead. If you see that crash Florian mentions, please let me know, so we can fix > it. > I will try once the release candidate is out. Laszlo [1] http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/39385.aspx -- 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 0014005]: terminate called after throwing an instance of 'std::logic_error'
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14005
==
Reported By:Alexander Polunin
Assigned To:
==
Project:CMake
Issue ID: 14005
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-03-12 16:53 EDT
Last Modified: 2013-03-12 16:53 EDT
==
Summary:terminate called after throwing an instance of
'std::logic_error'
Description:
cmake source files contain places where you construct std::basic_string from
NULL pointer of type const char*. And this leads to cmake termination after
throwing std::logic_error exception. Maybe it's not the big problem if you sure
that NULL pointers are impossible but at least in one case simple input to cmake
leads to its termination in string
"cmake-2.8.10.2/Source/kwsys/SystemTools.cxx:1803".
kwsys_stl::string SystemTools::ConvertToUnixOutputPath(const char* path)
{
kwsys_stl::string ret = path; // maybe we need to more strict check here
...
Steps to Reproduce:
1) create CMakeLists.txt with content
Begin##
include (CTest)
project(ttt)
End#
2) create build folder and go there
3) run cmake with default generator (I have checked it with gcc and MinGW
toolchain)
cmake ..
4) see
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_S_construct null not valid
==
Issue History
Date ModifiedUsername FieldChange
==
2013-03-12 16:53 Alexander PoluninNew 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] Modules/Compiler: TI DSP/ARM
On Tuesday 12 March 2013, Laszlo Papp wrote: > Hi, > > I would like to note that the TI-DSP-ASM/C/CXX.cmake files would look like > exactly the same for TI-ARM-ASM/C/CXX.cmake. The interface is the same for > both toolchains. I presume you can just remove the DSP in there from the > file name (or in worse case, add an arm overload)? oh, this is working for you too ? Cool :-) Do you know for which other processors TI has a similar toolchain ? Simply naming it "TI" is quite general, so I'd like to be sure. Otherwise I'll have a look around tomorrow. If you see that crash Florian mentions, please let me know, so we can fix it. Thanks 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] Modules/Compiler: TI DSP/ARM
Hi, I would like to note that the TI-DSP-ASM/C/CXX.cmake files would look like exactly the same for TI-ARM-ASM/C/CXX.cmake. The interface is the same for both toolchains. I presume you can just remove the DSP in there from the file name (or in worse case, add an arm overload)? http://cmake.org/gitweb?p=cmake.git;a=tree;f=Modules/Compiler;h=34a0ad1a5694082dc8ffc62c2ebeaa446ea09274;hb=master Laszlo -- 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 0014004]: FindSDL fails to find headers for cross-compilation
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14004
==
Reported By:Quintus
Assigned To:
==
Project:CMake
Issue ID: 14004
Category: Modules
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2013-03-12 12:51 EDT
Last Modified: 2013-03-12 12:51 EDT
==
Summary:FindSDL fails to find headers for cross-compilation
Description:
FindSDL fails to find the SDL include headers for cross compilation. I have a
MXE (http://mxe.cc) cross-compilation environment set up at
$HOME/win32/mxe/usr/i686-pc-mingw32 which includes a cross-compiled SDL library
for mingw32 (the host system is a 64-bit Arch Linux). Here’s a list of all
SDL-related files installed under that root directory: http://pastie.org/6461937
Exact error from CMake:
CMake Error at
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (message):
Could NOT find SDL (missing: SDL_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:291
(_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-2.8/Modules/FindSDL.cmake:178
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:40 (find_package)
In order to cross-compile, I then set CMAKE_FIND_ROOT_PATH in my toolchain file:
set(CMAKE_SYSTEM_NAME Windows)
set(CMAKE_FIND_ROOT_PATH "$ENV{HOME}/win32/mxe/usr/i686-pc-mingw32")
And of course, I also set the other necessary variables:
set(CMAKE_C_COMPILER i686-pc-mingw32-gcc)
set(CMAKE_CXX_COMPILER i686-pc-mingw32-g++)
set(CMAKE_RC_COMPILER i686-pc-mingw32-windres)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
This is the cross-compiler:
% i686-pc-mingw32-gcc --version
i686-pc-mingw32-gcc (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Steps to Reproduce:
1. Create a SDL installation for mingw32 somewhere
2. Create CMakeLists.txt that calls find_package(SDL REQUIRED)
3. Create a toolchain file for cross-compilation from Linux to mingw32,
variables see above, ensure CMAKE_FIND_ROOT_PATH includes the root of your SDL
installation
4. Invoke CMake with -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain/file
5. CMake fails to find the SDL headers.
==
Issue History
Date ModifiedUsername FieldChange
==
2013-03-12 12:51 QuintusNew 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] Documentation tweaks
On 03/12/2013 04:48 AM, Petr Kmoch wrote: > I've created a small patch with a few minor documentation > enhancements, mainly things I was looking for in the docs but didn't > find them there. I hope you find it useful. Thanks, applied: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3cf2f67a -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] Documentation tweaks
Hi all, I've created a small patch with a few minor documentation enhancements, mainly things I was looking for in the docs but didn't find them there. I hope you find it useful. Petr 0001-Enhnance-documentation.patch Description: Binary data -- 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 0014003]: Add SEMICOLON generator expression
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=14003 == Reported By:Jean-Christophe Fillion-Robin Assigned To: == Project:CMake Issue ID: 14003 Category: CMake Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2013-03-12 09:22 WAST Last Modified: 2013-03-12 09:22 WAST == Summary:Add SEMICOLON generator expression Description: This is useful to add test using ExternalData_add_test and allow test parameter to contain semicolon. Patch: https://github.com/jcfr/CMake/tree/external-data-support-for-param-with-semicolon Small project to illustrate: https://gist.github.com/jcfr/5137833#file-cmakelists-txt == Issue History Date ModifiedUsername FieldChange == 2013-03-12 09:22 Jean-Christophe Fillion-RobinNew 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
