KDevelop can't load project: "too large document"?

Matthew Woehlke mwoehlke.floss at gmail.com
Wed Dec 6 19:52:24 GMT 2017

On 2017-12-06 12:56, René J.V. Bertin wrote:
> On Wednesday December 06 2017 12:26:26 Matthew Woehlke wrote:
>> (I'm building RelWithDebInfo, so I assume and expect asserts are
>> not enabled).
> (You can also use a custom build type and set the exact compiler 
> options you want via CFLAGS and CXXFLAGS in the environment. That
> way you're sure you won't get the benefit of all the advanced error
> handling implemented via asserts ;) )

Sure :-). That was more in line with noting why I didn't hit the assert
immediately when I tried the built-from-source version.

>> Handling an error from the *server* appears to be handled. The patch
>> hijacks this by synthesizing a response that looks like a server error,
>> and passing that back up the stack instead of the "real" response which
>> could not be parsed.
> OK, so what's the end result of this? Is the project imported using
> the older importer, or do you just get a failure message?
I'm... not sure? I seem to have identified targets, anyway...

(More critically, the project *loaded*, so at worst I guess I have the
equivalent of it being a generic project, but also with the build
integration, at least at the project level.)

Maybe it would be better for someone familiar with the code to test. It
should be easy enough to make the "codemodel" code path (in
CMakeServerImportJob::processResponse) emit an error a la the "error"
code path a couple lines below. This should have the same effect as when
the problem actually manifests.

> you might be able to implement a combined fix by setting the server
> import job's error flag to a non-zero value and making sure
> CMakeServerImportJob::result is emitted as soon as possible.
That... *might* be what is happening? Again, I am not familiar with the
code, so I am making many WAGs, but both the "codemodel" and "error"
response handlers call `emitResult()`, the latter having set an error first.

What confuses me is that code in cmakemanager.cpp makes me think that
*any* response from the job triggers a failure and falling back on the
"old" code.


More information about the KDevelop mailing list