[PROJ] "Unity" builds

Javier Jimenez Shaw j1 at jimenezshaw.com
Mon Nov 27 08:43:34 PST 2023


Hi Even

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).
Mixing CI instances with and without it should cover all the cases.
(I am not a fan of unity, but I see it can be useful)

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.

For packagers: it is NOT recommended (AFAIK) to make a release with UNITY
option ON.

Cheers.

On Mon, 27 Nov 2023 at 17:03, Even Rouault via PROJ <proj at lists.osgeo.org>
wrote:

> Hi,
>
> Few days ago I've proposed in https://github.com/OSGeo/PROJ/pull/3962 to
> add the capability to enable "unity" / "jumbo" builds (for the core
> library), through CMake's -DCMAKE_UNITY_BUILD=ON.
>
> Basically CMake concatenates a few .cpp file until it generates a
> translation unit that is big enough but not too big. That can result in
> twice faster builds (at least for libproj, excluding tests or proj.db
> generation). But as code is not always ready to be concatenated with
> other files, I had to do quite a lot of changes for that (like making
> sure to #undef stuff at end of .cpp files, or that structures in
> anonymous namespaces or static functions have unique names), which by
> themselves should be harmless (and also makes it easier to debug, as
> instead of having >10 static setup() functions, they have a distinct
> name now) when doing regular builds.
>
> But as discussed in the PR this feature isn't entirely riskless when
> enabled, so this capability is not enabled by default and there will be
> a note in the doc about that (cf my last comment in the PR).
>
> That said, in some cases unity builds might be useful to uncover latent
> bugs (I've for example spotted that way a latent bug in GDAL where a
> file was relying on a undefined behaviour, and we were lucky compilers
> did compile it the way we intended it for regular builds), or identify
> some ODR (One Definition Rule) violations.
>
> CI has a mix of non-unity and unity builds (most configs are already
> doing a shared and a static build. so typically one of them is done with
> a default build and the other one with a unity one)
>
> Is there some agreement to merge that? (master only of course)
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20231127/d7ddade4/attachment.htm>


More information about the PROJ mailing list