[cmake-developers] linked-usage-cleanup regressed automoc

Alexander Neundorf neundorf at kde.org
Tue Mar 12 18:08:22 EDT 2013


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



More information about the cmake-developers mailing list