<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 7 Jul 2019 at 16:32, René J.V. Bertin <<a href="mailto:rjvbertin@gmail.com">rjvbertin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sunday July 07 2019 15:43:46 Steve the Fiddle wrote:<br>
<br>
Replying through the list, because of something you said.<br>
<br>
> > I think your best bet would be to use Audacity's CMake file because this<br>
> > should remove the need for most custom header search paths.> How do I do that?<br>
> Do you mean:<br>
> "Project  menu > Open Configuration > Make > Make executable => <actual<br>
> path>/audacity/CMakeLists.txt"<br>
> <br>
> If so, that does not appear to make any difference.<br>
<br>
No, you open a new project, loading it from the CMakeLists.txt file<br></blockquote><div><br></div><div>"Project menu > Open / Import Project" does not allow me to select a file, only a directory.</div><div>How do I load a project from CMakeLists.txt?</div><div><br></div><div>Steve<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Sorry but I've no idea what you mean.<br>
> Currently when building, I create a "/build" directory within the main<br>
> source root folder, then configure / make from the command line with:<br>
> ../configure <options><br>
<br>
^^^ 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.<br>
<br>
What I meant is something like this, if your audacity code lives in /path/to/audacity-src:<br>
<br>
%> cd /path/to<br>
%> mkdir audacity-build<br>
%> (cd audacity-build ; cmake [cmake-options] ../audacity-src)<br>
%> cd audacity-src<br>
%> configure [options]<br>
%> make<br>
<br>
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.<br>
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.<br>
<br>
> > If KDevelop finds the .h files but doesn't recognise classes in them it<br>
> > usually means that some kind of macro isn't set.<br>
> ><br>
> <br>
> How would I chase that down and fix it?<br>
<br>
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 .<br>
<br>
> I'll leave that for now as I would need more detailed documentation so that<br>
> I don't have to "figure out" things that I've zero understanding about.<br>
<br>
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. (<a href="http://bugs.kde.org" rel="noreferrer" target="_blank">bugs.kde.org</a> will let you check if your bug has already been reported.)<br>
<br>
R<br>
</blockquote></div></div>