C++ header files and crash issue

[Steve the Fiddle]

On Mon, 8 Jul 2019 at 09:42, René J.V. Bertin <rjvbertin at gmail.com> wrote:

> Steve the Fiddle wrote on 20190707::23:54:37 re: "Re: C++ header files and
> crash issue"
>
>
> >> >What do you mean "included via a compiler argument"?
> >>
> >> The `-include foo.h` compiler option tells the compiler to include a
> >> headerfile before including the headerfiles from the #include
> statements in
> >> the source code.
> >>
> >
> >Where are you looking? Where will I see these compiler arguments that you
> >refer to?
> >
> >
> >>
> >> >The compiler arguments that I use (successfully) are:
> >> >../configure --with-lib-preference="local system"
> --with-ffmpeg="system"
> >> >--disable-dynamic-loading --with-mod-script-pipe --with-mod-nyq-bench
> >> >--enable-debug
> >>
> >> Those are not compiler arguments! They are configuration arguments that
> >> specify how you want the project to be built.
>
>
> Steve, no offense, but may I suggest that you read up on the basics of
> software development on Unix/Linux?
>
> The `-include AudacityHeaders.h` directive is added in src/CMakeLists.txt .
>

OK, I think I see where we are getting our wires crossed. On Linux,
Audacity is built with make, not cmake (apart from libsoxr if I recall
correctly). Cmake is currently experimental for Audacity, and only worked
on Windows last time I looked. As you noticed yourself, some of the
includes in
 src/CMakeLists.txt are hard wired for Windows.


> >> >Interesting. Is there any documentation about custom defines in
> kDevelop?
> >> >How did you know to add those custom defines?
>
> Because I noticed what I mentioned earlier, that KDevelop's parser did not
> "see" certain parts of the code that were protected by #ifdefs.
>

OK, got it.
I've also noticed that kDevelop does not "see" parts that are within
#if USE_SOUNDTOUCH
or
#if USE_SBSMS

so I added in "Configure language support > Defines"

*Define:              Value:*
USE_SOUNDTOUCH        1
USE_SBSMS             1

and now it sees those parts.
That's a big help (cartoon lightbulb moment). Thanks René.


>
> >I don't see where it explains how to correctly set up include paths
> either.
> >Do I need to manually add every directory in the project?
> >Yes, I've seen where to add defines, but Audacity has hundreds of defines.
> >How did you know which defines needed to be added to kDevelop's
> >configuration?
>
> Maybe, maybe not. This will become clear when you edit files... I added
> the directories and defines that I discovered were missing. Maybe I'll
> discover others when I need to visit other parts of the code, maybe not.
>
> >Is there anyone in the kDevelop team that might be interested in, a)
> fixing
> >the crash bug, b) helping the Audacity team to document setting up
> kDevelop
> >for use with Audacity's code? Perhaps we can come to some arrangement that
> >gives mutual benefit.
>
> I think that the best thing the Audacity team could do at this point is to
> work out any remaining kinks with their CMake implementation and make sure
> it works on all platforms (Mac included), with all the same custom
> configuration options as the configure script offers.


Unfortunately this is a bit of a catch 22. We are currently lacking in
developers that use Linux as their primary OS. The build system is
currently pretty  robust on Windows (using MSVS) and on macOS (using
xcode). We previously had a Linux developer that was very keen on make /
autotools, hence our reliance on that tool chain on Linux. Personally I
would very much like us to use cmake on all platforms, but I don't have the
knowledge or experience to do that (I'm mostly support + documentation, and
only dabble in C++).


> Be sure to add some documentation for less evident feature such as how to
> indicate where wxWidgets is installed (I had to dig out CMake's
> FindwxWidgets file and scan through it to *guess* that I needed to add
> `-DwxWidgets_CONFIG_EXECUTABLE=/opt/local/libexec/wxWidgets/3.1/bin/wx-config`
> on my system).
>

In most cases, when building from the command line, Audacity will build
against a system installed wxWidgets without needing to specify where it is
installed.

If using a local build of wxWidgets, the path is passed as a configure
argument, for example:
./configure WX_CONFIG=/home/user/dev/wxbuild/wx-config
as documented on this old page:
https://wiki.audacityteam.org/wiki/Developing_On_Linux


>
> Once you have an exhaustive formal description of how Audacity has to be
> built in CMake language this "model" will also be available to KDevelop. If
> there are still probems then it may be more efficient to discuss them on
> the kdevelop-devel mailing list.
> But mind you, I too have had the impression that the KDevelop team has
> been less reactive (and development may even have slowed a bit). So the
> most efficient approach may still be to figure out a fix to your problem
> yourself and then present it for review. That generally works better here
> anyway, rather than asking to fix your problems for you...
>

Thank you very much for your time René. I wasn't intending my comments to
come across as asking someone to fix my problems. I'm more than happy to
rtfm, but when the necessary documentation cannot be found, I have to ask.

Also, regardless of what's in the Audacity code, kDevelop shouldn't choke
and crash. It might even be something that could be  leveraged into an
exploit against KDevelop. The crash is 100% repeatable for me with both the
current kDevelop AppImage, and the previous 5.2 version. I'd be surprised
if it is not repeatable for other users with that (Audacity) code and the
kDevelop AppImage. If this email list is not the correct place to report
crash problems, I'll be happy to repost this specific issue if you can
point me to the correct place.

Thanks again.
Steve


>
> R.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop/attachments/20190708/ace8da10/attachment.html>