<div dir="ltr"><div dir="ltr"><div>Hi 
Miklos,</div><div></div><div><br></div><br><div>I totally agree that ideally, if the 'right' way to set these flags for this build system is setting 'gb_GCOV=YES' on the make commandline, then this should be fixed. However, I have no knowledge of this particular build system or makefiles in general, so I am unable to fix that myself. So instead, I tried setting these *FLAGS on the autogen.sh line, which also made it work. So it is not so much my preferred way of doing things; merely a result of my understanding / lack of understanding of certain areas of expertise. <br><br>As for checking if skia gets built with gcc instead of skipped when clang is not available, what would be the best way to verify that ? I guess that after the build a 'libskia.so' or something should be present ? I have a './instdir/program/libskialo.so', after a gcov build, would that be it ?<br><br>By the way, there is a script that assists/attempts to automate doing a gcov code coverage report (full build / make check) [1] (which I wrote, by the way, back in 2015 or something), but looking at it now it is not all that user friendly and/or overengineered. Usage consists of running the script in different 'steps', and then running 'make check' in between. I *think* I did it that way in order to make it as flexible as possible, which seems silly now as it will only get run for the LibreOffice codebase anyway. The idea was that once I got code coverage for a full build working again 'in principle', that I take another look at that script and make it do all the steps in one go, and then see if there is enough interest to run that automatically on a regular basis somewhere.<br><br><br>[1]<br><a href="https://git.libreoffice.org/buildbot/+/refs/heads/master/lcov-report/">https://git.libreoffice.org/buildbot/+/refs/heads/master/lcov-report/</a><br><br><br>- Maarten</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 31, 2022 at 8:52 AM Miklos Vajna <<a href="mailto:vmiklos@collabora.com">vmiklos@collabora.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">Hi Maarten,<br>
<br>
On Fri, May 27, 2022 at 10:26:21AM +0200, Maarten Hoes <<a href="mailto:hoes.maarten@gmail.com" target="_blank">hoes.maarten@gmail.com</a>> wrote:<br>
> CFLAGS='-fprofile-arcs -ftest-coverage' CXXFLAGS='-fprofile-arcs<br>
> -ftest-coverage' LDFLAGS='-fprofile-arcs -lgcov' ./autogen.sh<br>
> --enable-python=internal --without-system-libs --without-system-headers<br>
> gb_GCOV=YES verbose=t make --output-sync=target<br>
> gb_GCOV=YES verbose=t make check -k --output-sync=target<br>
<br>
I believe that manually specifying CFLAGS/CXXFLAGS/LDFLAGS is not<br>
necessary for coverage, and if you run into problems, we should rather<br>
fix that.<br>
<br>
> I recently started a thread [1] that is about the (complete, not partial)<br>
> build with gcov failing for me if I only set 'gb_GCOV=YES' on the make<br>
> commandline. The build succeeds for me if I also set the required *FLAGS on<br>
> the autogen commandline. The failing parts when only using 'gb_GCOV=YES'<br>
> were/are 'liborcus' and 'expat'.<br>
<br>
I wonder if then our makefiles for liborcus / expat should be fixed to<br>
take flags set by gb_GCOV at solenv/gbuild/platform/com_GCC_defs.mk:117<br>
into account?<br>
<br>
> Skia (I think) initially also broke the<br>
> build, but that was because of conflicts between clang and gcc [2], which<br>
> was resolved when I uninstalled clang. If I understand correctly, it was<br>
> intended to force skia to always be built with clang, but - intended or not<br>
> - at least on Linux it falls back on gcc (or skia gets skipped perhaps).<br>
<br>
Building skia with clang is about helping performance, so you're fine to<br>
fall back to gcc, probably. Disabling skia completely would mean you<br>
don't get coverage for the code that integrates skia with the rest of<br>
LO, which is probably not great.<br>
<br>
> When looking at 'coverage.sh', it seems it only covers specific parts of<br>
> the build, and not everything, so perhaps it doesn't build the parts that<br>
> fail for me when not setting the additional *FLAGS ?<br>
<br>
Yes, coverage.sh is only a partial rebuild, with the idea that if you<br>
work on an area anyway, then you may want to improve coverage where you<br>
have domain knowledge. Which has some overlap with your "get a global<br>
picture" goal, but somewhat different. :-)<br>
<br>
> Anyway, if you feel that setting the additional *FLAGS in addition to<br>
> 'gb_GCOV=YES' is not the right way to address the problem of the full build<br>
> with gcov failing for me, then perhaps we should revisit that thread [1],<br>
> before we continue looking at why 'make check' fails for me ?<br>
<br>
My suggestion would be to just keep the above in mind. Obviously there<br>
is value in getting a full make check working with coverage *somehow*,<br>
so if you have a preference how you do that, feel free to go ahead that<br>
way. It just seemed weird that those global compiler/linker flags are<br>
set in your build: gb_GCOV is ideally enough to set all of these.<br>
<br>
Regards,<br>
<br>
Miklos<br>
</blockquote></div></div>