C++ header files and crash issue

[René J.V. Bertin]

On Sunday July 07 2019 15:43:46 Steve the Fiddle wrote:

Replying through the list, because of something you said.

> > I think your best bet would be to use Audacity's CMake file because this
> > should remove the need for most custom header search paths.> How do I do that?
> Do you mean:
> "Project  menu > Open Configuration > Make > Make executable => <actual
> path>/audacity/CMakeLists.txt"
> 
> If so, that does not appear to make any difference.

No, you open a new project, loading it from the CMakeLists.txt file

> Sorry but I've no idea what you mean.
> Currently when building, I create a "/build" directory within the main
> source root folder, then configure / make from the command line with:
> ../configure <options>

^^^ that is one reason why you are running into difficulties I think. I have never managed to get KDevelop work correctly with standard Makefile projects (including those using autoconf/automake) where the build is not done in the source directory. KDevelop tends to see only the files that are present in the build directory, when I try this.

What I meant is something like this, if your audacity code lives in /path/to/audacity-src:

%> cd /path/to
%> mkdir audacity-build
%> (cd audacity-build ; cmake [cmake-options] ../audacity-src)
%> cd audacity-src
%> configure [options]
%> make

I would then create a KDevelop project from /path/to/audacity-src/CMakeLists.txt and tell the new-project wizard to use /path/to/audacity-build as the build dir. It will realise the build is already configured, but you can still enter your cmake options in the dedicated entry field.
With this approach you would of course get a separate build if you let KDevelop compile the code. I rarely ever do that, for various reasons, and I wouldn't advise that you build via the cmake mechanism given that you're not familiar with it ... and I not certain that it is production-ready for Audacity.

> > If KDevelop finds the .h files but doesn't recognise classes in them it
> > usually means that some kind of macro isn't set.
> >
> 
> How would I chase that down and fix it?

If this is the case you will see that the code isn't colourised when you open the .h file in KDevelop. You can then find the #ifdef(s) around that code and see if any use a token that KDevelop cannot know about. That would basically be any token that is set in a Makefile instead of in, say, the project's config.h .

> I'll leave that for now as I would need more detailed documentation so that
> I don't have to "figure out" things that I've zero understanding about.

One thing you can try is the KDevelop app-image. I suppose it will have its own libclang. If it crashes too you can do the same kind of trick with the debugger to get a backtrace, and use that to report a bug. I would reckon that one of the devs would have chimed in to say that they have an idea what the problem is here; since they didn't I can only suppose they will welcome a report that's based on a set of binaries they generate themselves. (bugs.kde.org will let you check if your bug has already been reported.)

R