Re: C++ header files and crash issue

On Sun, 7 Jul 2019 at 16:32, René J.V. Bertin <[email protected]> wrote:

> 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
>

"Project menu > Open / Import Project" does not allow me to select a file,
only a directory.
How do I load a project from CMakeLists.txt?

Steve


>
> > 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
>