[poppler] Last, Few Build Questions

[Albert Astals Cid]

El dijous, 24 de setembre de 2020, a les 3:21:00 CEST, Kyle Auble va escriure:
> I've mostly finished going over the build-system, but I had a few last
> questions. The mailing-list seemed more appropriate since I don't think
> they're necessarily issues with Poppler:
> 
> 1. If I try to build with clang & sanitizers enabled, GObject-
> introspection (all sanitizers) fails to link. There's already a known
> asan error with GObject-introspection that's tracked upstream at:
> https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/176
> 
> However, if I configure to build with clang, I don't even reach that
> point. My logs show g-ir-scanner trying to link with gcc anyways, then
> failing to find the sanitizer libraries.
> 
> * I'm leaning towards g-ir-scanner being the cause, but could it be a
> Poppler issue? I didn't notice any obvious causes while skimming the
> CMake files. Google didn't turn up clear reports of this override
> happening anywhere else though.

I know nothing of glib stuff, you'll have to hope someone else answers.

> 
> 2. The GLib tests also fail at linking if ubsan is enabled. The cause is
> that some of the triggered ubsan checks are only provided in the C++
> sanitizer library, while CMake defaults to linking the C library once it
> sees the tests are .c files.
> 
> It only takes one line setting `LINKER_LANGUAGE` to "CXX" for those
> targets to build successfully, but that seems too brittle to count as a
> solution, unless it's applied to the entire build tree.
> 
> * At that point, I'm thinking it's more of an issue with extra-cmake-
> modules for not checking & handling this behavior.

Yes, probably a ECM issue, when we did code that we didn't think of C-only code, KDE doesn't have much of those, patches to https://invent.kde.org/frameworks/extra-cmake-modules/ welcome. Add me @aacid as reviewer if you do :)

> 3. For the project generally, how much appetite is there for minor code
> refactoring? Do you all prefer "if it ain't broke, don't fix it", or do
> you typically accept minor changes to streamline the code?

Patches that defenitely make the code better are accepted. But of course you have to accept we may disagree on what "makes the code better" mean.

Cheers,
  Albert

> 
> Kyle
>