<div dir="ltr"><div>Hi Even</div><div><br></div><div>Thanks for the work. As you say, having the option is useful. It is true that anonymous namespaces are not anonymous any more, but I hope it is not big problem (you already suffered the consequences).<br></div><div>Mixing CI instances with and without it should cover all the cases.</div><div>(I am not a fan of unity, but I see it can be useful)</div><div><br></div><div>Note for developers: if the code compiles perfectly in your computer, but some CI instances are complaining about duplicated symbols, function X already defined or similar things, it can be unity.<br></div><div><br></div><div>For packagers: it is NOT recommended (AFAIK) to make a release with UNITY option ON.</div><div><br></div><div>Cheers.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 27 Nov 2023 at 17:03, Even Rouault via PROJ <<a href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</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,<br>
<br>
Few days ago I've proposed in <a href="https://github.com/OSGeo/PROJ/pull/3962" rel="noreferrer" target="_blank">https://github.com/OSGeo/PROJ/pull/3962</a> to <br>
add the capability to enable "unity" / "jumbo" builds (for the core <br>
library), through CMake's -DCMAKE_UNITY_BUILD=ON.<br>
<br>
Basically CMake concatenates a few .cpp file until it generates a <br>
translation unit that is big enough but not too big. That can result in <br>
twice faster builds (at least for libproj, excluding tests or proj.db <br>
generation). But as code is not always ready to be concatenated with <br>
other files, I had to do quite a lot of changes for that (like making <br>
sure to #undef stuff at end of .cpp files, or that structures in <br>
anonymous namespaces or static functions have unique names), which by <br>
themselves should be harmless (and also makes it easier to debug, as <br>
instead of having >10 static setup() functions, they have a distinct <br>
name now) when doing regular builds.<br>
<br>
But as discussed in the PR this feature isn't entirely riskless when <br>
enabled, so this capability is not enabled by default and there will be <br>
a note in the doc about that (cf my last comment in the PR).<br>
<br>
That said, in some cases unity builds might be useful to uncover latent <br>
bugs (I've for example spotted that way a latent bug in GDAL where a <br>
file was relying on a undefined behaviour, and we were lucky compilers <br>
did compile it the way we intended it for regular builds), or identify <br>
some ODR (One Definition Rule) violations.<br>
<br>
CI has a mix of non-unity and unity builds (most configs are already <br>
doing a shared and a static build. so typically one of them is done with <br>
a default build and the other one with a unity one)<br>
<br>
Is there some agreement to merge that? (master only of course)<br>
<br>
Even<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>