Try switching to Meson builds

[pkgw]

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

The main motivation here is to try addressing #49 and to fix conda-forge/tectonic-feedstock#49, which is having a link error on Windows that could maybe be fixable in the old system, but seems to get fixed for free with the Meson switch.

Windows relocatability

I spent a while trying to make sure that the Windows packages relocate well. Some notes from the time I spent on this:

• Note that the patch to put the prefix in FONTCONFIG_FILE isn't applied on Windows!
• But the build prefix gets embedded into the DLL code via the FC_CACHEDIR, CONFIGDIR, and FC_TEMPLATEDIR preprocessor defines
• But also Conda's prefix-rewriting basically doesn't actually do anything for binary files on Windows! It only rewrites a very specific shebang pattern
• So the resulting Conda package embeds the build prefix in the generated DLL and it doesn't get rewritten
• But with our build patches, we end up reading the correct config file if the executing binary is in Library/bin

Other notes

• The new Windows build doesn't include the Shift Media Project headers anymore. Among other things, this means that the CLI programs on Windows now basically lose any non-trivial argument handling, since the getopt headers aren't found. I tried a basic change to get Meson to find getopt using the SMP headers. It didn't work but I didn't debug.
• If I'm reading the Meson build scripts correctly, the macOS builds should now get a good default list of font search directories automatically, rather than us needing to specify them in build.sh
• This changes the XML implementation from libxml2 to expat

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• If python is a host requirement, it should be a run requirement.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[pkgw]

@conda-forge/fontconfig OK, it took me a bunch of tries to get the cross builds to work, but I think this is ready for review now. Besides cleaning up the build scripts substantially, I think this should fix a couple of the bugs mentioned above.

[pkgw]

@ocefpaf would you have a chance to review this? It's blocking my Tectonic package update.

[djhoese]

This seems to be causing errors when importing rasterio on OSX:

../../../miniconda3/envs/test-environment/lib/python3.10/site-packages/rasterio/__init__.py:9: in <module>
    from rasterio._base import gdal_version
E   ImportError: dlopen(/Users/runner/miniconda3/envs/test-environment/lib/python3.10/site-packages/rasterio/_base.cpython-310-darwin.so, 2): Library not loaded: @rpath/libfontconfig.1.dylib
E     Referenced from: /Users/runner/miniconda3/envs/test-environment/lib/libpoppler.117.0.0.dylib
E     Reason: Incompatible library version: libpoppler.117.dylib requires version 14.0.0 or later, but libfontconfig.1.dylib provides version 13.0.0

Note this was a brand new environment in my CI where the PR job passed, a couple hours later I merged it, and then the OSX job failed in main.

[pkgw]

Hmm, the current situation is a little confusing to me, but it at least looks plausible that the Meson build system drops the library version number down compared to Autoconf. Here's what I think is the relevant code from meson.build:

# Try and maintain compatibility with the previous libtool versioning
# (this is a bit of a hack, but it should work fine for our case where
# API is added, in which case LT_AGE and LIBT_CURRENT are both increased)
soversion = fc_version_major - 1
curversion = fc_version_minor - 1
libversion = '@0@.@1@.0'.format(soversion, curversion)
defversion = '@0@.@1@'.format(curversion, fc_version_micro)
osxversion = curversion + 1

So the osxversion here should work out to 13 as being reported. The only relevant-looking setting that I can find in configure.ac is

LIBT_CURRENT=13

and I guess based on the meson.build that maybe the macOS version is that plus one?

I don't have a sense of how many packages we have on macOS that depend on fontconfig. I think I'd rather rebuild them than patch our fontconfig dylib versions, and I think that would fix the problem. But on the other hand I'm pretty sure the latter would really be a one-line patch. Anyone else have an opinion?

[xylar]

This is also causing trouble with gdal: https://github.com/conda-forge/gdal-feedstock/pull/611

[xylar]

If I understand right, a rebuild of poppler (the gdal dependency that's complaining) should fix this?

[xylar]

I'm only seeing 7 feedstocks that use fontconfig: https://github.com/search?q=org%3Aconda-forge+fontconfig+filename%3Ameta.yaml&type=Code&ref=advsearch&l=&l= But poppler doesn't show up in this list for some reason, which makes me think it might not be complete.

[zklaus]

Could it be possible/reasonable to have a migration for this?

[pkgw]

@xylar Yes I believe that rebuild ought to be all that's necessary. (And since the version number is lower, I believe that it would also maintain compatibility with older versions of the package, because I don't believe that the ABI is actually any different.)

edit: Also, yeah, the GitHub search looks like it is very incomplete. I can't see any obvious reason for it not to be finding some of the other feedstocks that use it, so I guess the feature is just unreliable that way.

@zklaus I don't know the migration system super well, but I think so? It would be ideal if the migration could be limited to packages with macOS builds, but if not, that shouldn't be a huge issue either.

[zklaus]

@pkgw, good points. I guess another reason to put some effort into the platform filtering option discussed here.

[xylar]

Funny about the GitHub search. I get different numbers of hits each time I refresh -- as many as 52! But that feature has worked reliably for me in the past so I wonder if something's going wrong today.