On Sat, 13 Mar 2021 00:15:16 GMT, Phil Race <p...@openjdk.org> wrote:
> From a build perspective this partially reverts > https://bugs.openjdk.java.net/browse/JDK-8249821 except that it keeps > the harfbuzz sources separate and still supports building and running against > a system harfbuzz which is only of interest or relevance on Linux. > > I ended up having to go this way because its is the least unsatisfactory > solution. > I did not want us to build a devkit to link against a system linux only to > find we couldn't use it at runtime > because too many systems have to old a version of harfbuzz. > > This solves the Manjaro Linux problem and I've manually verified building > against a system hardbuxz on Ubuntu 20.10 > > There are couple of incidental fixes in here too > - "libharfbuzz" should not have been in the EXTRA_HEADERS var when building > against a system version > - harfbuzz/hb-ucdn is gone and should not be listed as a header directory > needed to build the bundled copy > - I expect it also resolves https://bugs.openjdk.java.net/browse/JDK-8262502 > Just thinking out loud, you don't think it would be better to build harfbuzz > separately, but as a static library, that is then included in libfontmanager? > The main win of doing that, I think, is the ability to have all the disabled > warnings confined to the lower-quality upstream source. The resulting code > would be the same. And from a build performance perspective I don't think any > way of doing it matters. I don't know that this would be worth such an effort. I've clearly separated the warnings we are disabling for HARFBUZZ and there's really not a lot of likelihood in my mind that these warnings will suddenly also start to apply to the small amount of JDK code that is in libfontmanager which is also much simpler code. BTW I noticed we are still disabling all warnings for sunFont.c and after this is done I'll likely see if I can make a source code change to resolve that. ------------- PR: https://git.openjdk.java.net/jdk/pull/2982
