Without thinking too much, I would be -1 on
committing workarounds to code to make this work, or support for it.
It feels like a lot of complexity for no real gain.
We can always retract from them if they turn to be an inconvenience...
The major inconvenience has been the effort to bootstrap that
capability. I don't think the state of the codebase has been damaged in
the process. Avoiding having functions or structures with the same name
makes navigating the code base easier IMHO.
Mozilla supports both unity & non-unity builds. Actually in
https://serge-sans-paille.github.io/pythran-stories/how-unity-builds-crept-into-the-firefox-build-system.html
they mention that until recently, they only supported unity builds, and
fixed stuff to support non-unity builds as well.
Assuming you have set up ccache if you are concerned about build times,
do you find that it's a real issue?
That can be convenient for developers touching "root" header files that
trigger a full rebuild of the whole code base.
This was mostly an experiment on a "small" project to see if that
produced actual speed-up. There real target I chased was for GDAL where
build times are much longer than PROJ, and I got the same effects.
And as I mentioned unity builds can help uncover non-compliance.
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
