[libvips] new port

[angelmixu]

• Changes comply with the maintainer guide.
• The packaged project shows strong association with the chosen port name. Check this box if at least one of the following criteria is met:
  • The project is in Repology: https://repology.org//versions
  • The project is amongst the first web search results for "" or " C++". Include a screenshot of the search engine results in the PR.
  • The port name follows the 'GitHubOrg-GitHubRepo' form or equivalent Owner-Project form.
• Optional dependencies of the build are all controlled by the port. A dependency is controlled if it is declared an unconditional dependency in vcpkg.json, or explicitly disabled through patches or build system arguments such as CMAKE_DISABLE_FIND_PACKAGE_Xxx or VCPKG_LOCK_FIND_PACKAGE
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is brief and accurate. See adding-usage for context. Don't add a usage file if the automatically generated usage is correct.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

Hey folkz!

I'd like to add the libvips port :) ( https://github.com/libvips/libvips )
I know it has lib as prefix, but if you look for it everywhere is using libvips as the name, also, the github repo is called libvips/libvips.
In repoloy webpage I can see some repositories using it as libvips, or as vips only. (BTW: the https://repology.org//versions url doesn't seem to work)

libvips on google:

Furthermore, if you remove the lib prefix, you can confound it with a sandwich restaurants chain :P

vips on google:

I'll let the owner and team of libvips/vips about this PR for if they want to say anything too.

Let me know if I should change the port name to vips only instead.

A couple thing that I'd like to discuss:

• At this moment I needed to use the head version for Windows because the current release has a bug which prevents to be built.
  I set this in the portfile in the meantime:

#TODO: look for a way to use the --head version for port development
set(VCPKG_USE_HEAD_VERSION TRUE)

Is there any workaround to use the --head flag from my projects' vcpkg.json manifest?
I was taking a look at this conversation: #17805 but I didn't find any way to force using head version.

• I've put some optional dependencies as features in the port, they're listed here:
  ** https://github.com/libvips/libvips?tab=readme-ov-file#optional-dependencies
  ** https://github.com/libvips/libvips/blob/master/meson_options.txt
  Is there a way to automatically parse those options in the .txt file and provide them in the vcpkg.json or in any other way so we don't have to keep maintaining the port if anything upstream changes?
  I guess that if there's no way, I should put every option in libvips as a feature in vcpkg, isn't it?

• About the usage file, as it doesn't provide any cmake files to use, when building the port it shows the following snippet,I think it's enough, let me know if there's any better way to show it:

libvips provides pkg-config modules:

  # C++ API for vips8 image processing library
  vips-cpp

  # Image processing library
  vips

I'm still working on building and linking libvips with the project I'm working on, but I wanted to open this draft PR to discuss anything related or missing about the configuration in the different platforms so we can team up.

Let me know if there's any suggestion, improvement, etc.

Thanks! :)

[jcupitt]

Hello, libvips maintainer here.

This looks nice! I noticed:

• I think this should only build stable releases, not HEAD. If HEAD isn't working, let's fix it and delay this merge.
• I prefer the name "libvips", since "vips" is hard to search for.
• I would add some more dependencies. You can see the dependencies we use for our safe (ie. safe for untrusted files, and safe from arguments about licences) releases here: https://github.com/libvips/build-win64-mxe/tree/master?tab=readme-ov-file#libvips-web-dependencies
• It's possible to add other dependencies, but these can make libvips vulnerable to attack. or cause licence difficulties. The longer list is here: https://github.com/libvips/build-win64-mxe/tree/master?tab=readme-ov-file#libvips-all-dependencies
• You could also consider PDFium for PDF support, though this might be harder to integrate.

[angelmixu]

Hey @jcupitt thanks for coming by! :D

About using HEAD, it's for coming around an issue: libvips/libvips#4819
The change is from Jan 1st ( https://github.com/libvips/libvips/pull/4820/changes )
And the latest release is from Dec 17 2025 ( https://github.com/libvips/libvips/releases/tag/v8.18.0 )
So ideally it would be nice if we could get a 8.18.1 release with that fix for using a proper version in this port, and not HEAD.
I mean, using HEAD is only temporary while I'm building the port.

Thanks for the dependencies list, I think it's up to the comunity to choose which dependencies we need to support.
Or we could add support to every dependency and maybe set a warning when using a not safe one (I don't know if possible, but would be an option maybe).

BTW, regarding dependencies, I'd prefer any way to sync them automatically, so we don't have to keep maintaining different sources of truth every time there's an update

[jcupitt]

Regarding optional dependencies, I don't know the vcpkg policy here.

Homebrew's policy (for example) is to include all possible dependencies and hope that that reduces the need for source compiles by users.

libvips has a feature to make this safe: you can set the env var VIPS_BLOCK_UNTRUSTED and libvips will disable all untrusted loaders at runtime. Ideally the sense would be flipped (so you had to set VIPS_ALLOW_UNTRUSTED to get untrusted loaders to run), but ... we are where we are.

That won't fix licence issues though. For example, poppler is GPL and I expect many vcpkg users will not want to expose themselves to potential legal problems by using it. PDFium would be a safer choice, if possible.

[jcupitt]

We're hoping to get 8.18.1 done in a few days, so hopefully it's not a problem.

regarding dependencies, I'd prefer any way to sync them automatically

It's tricky, unfortunately. Every package manager uses different names for packages (!!!??! argh), and everyone will have strong views about which packages they should include or not include (eg. poppler vs. PDFium).

It would be hard to have a single source of truth :(

[angelmixu]

We're hoping to get 8.18.1 done in a few days, so hopefully it's not a problem.

awesome :D

Regarding dependencies, let's see if someone from vcpkg can tell us more about it.
I was looking how to approach it, and the only way I see is the features vcpkg.json parameter, and passing options into the portfile's vcpkg_configure_meson call.

[dg0yt]

meson.options is about configuration options, not about the actual dependencies.
There is no general (trivial) way to transform this into vcpkg.json features and dependencies.
There are also other considerations to apply to port features (such as being "additive").
And it is better to have a curated set of reasonable features than to blindly map every rarely used configuration option.

set(VCPKG_USE_HEAD_VERSION TRUE) is not acceptable here because it will use a random source. And it will eventually break. You could pick a particular commit instead (and choose version-date). Or you could apply specific patches. Or you could prepare the port (update) as draft until upstream makes a release with the desired changes. (I test curl release candidates with draft PRs.)

[angelmixu]

Yep, the idea is to wait for the new 8.18.1 version to use that one as official :)

And about options and dependencies, the idea also, was to make libvips with the lesser or default options as a minimal build, and through vcpkg features add those options like I have now for adding png support, tiff support, etc.

[jcupitt]

EDIT: oops, now I read a bit more I see vcpkg is source only, sorry for any confusion!

And about options and dependencies, the idea also, was to make libvips with the lesser or default options as a minimal build,

I think that would need users to compile the thing from source, wouldn't it? Doesn't vcpkg ship binaries?

libvips has a plugin mechanism which is used for loaders like heic and openslide, have a look in lib/modules:

$ ls ~/vips/lib/vips-modules-8.19/
vips-heif.so  vips-magick.so     vips-poppler.so
vips-jxl.so   vips-openslide.so

So those could be shipped separately as binaries, but I imagine that's probably too complex. It'd be simpler to have a separate eg. libvips-extras package.

[angelmixu]

Oh, I'm don't know about shipping binaries, I think I read somewhere it was discouraged unless it was really necessary.
Maybe an libvips-extra as you mention would be better. Let's see if someone can tell us something about it!

[angel-fiery]

Added the 'fix' for disabling fuzz in the meantime.

I think it's ready for merging if there's no issue in azure pipelines :)
Any suggestions or comments?

[angelmixu]

From the pr checks, they fail on building, but I can't see why.
I can't test most of the platforms that fail because I don't have access to that kind of machine 😅
Any suggestions?

[BillyONeal]

Does it make sense to try to build these when cross compiling?

[angelmixu]

ah, good question!
So far, I've seen people using the command line tools, so I wanted to let people have the option to copy them into the bin output directory.
When cross compiling I'd guess we would like to maintain them for anyone creating a package or distribution maybe?
@jcupitt what do you think?

[BillyONeal]

Marked draft due to build failures, please feel free to press Ready for review if you need another look.

Thanks for your submission!

[BillyONeal]

This feature isn't connected.

GPT-5.5 observes that

the tools feature is not connected to the build in 8.18.2: upstream has no tools Meson option for the portfile parser to enable, and vcpkg_copy_tools() currently runs unconditionally. This is blocking because the default package installs vips.exe, vipsedit.exe, vipsheader.exe, and vipsthumbnail.exe even when libvips[tools] is not selected.

[angelmixu]

ah yep, I'm copying tools directly because meson already builds them.
maybe I should check if the tools option is in the feature list and enable the copy in that case.
as John says, for 8.19 we should update the port because it already has the option in meson
should I do this?

[BillyONeal]

Drafting due to the unconnected feature and

@jcupitt what do you think?

above

[jcupitt]

Hi @BillyONeal,

git master libvips has a -Dtools option:

https://github.com/libvips/libvips/blob/master/meson_options.txt#L28-L31

This will be released as libvips 8.19 later this summer. I think the idea is that this vcpkg option will be connected up then.

[angelmixu]

Hi!

I removed the tools feature and put a comment so we can update the port when the new version is released.

The arm64_osx test fails because some "curl: (55) Send failure: No buffer space available", but other arches pass the test successfully, I understand it's not a port failure, isn't it?

I'll set this ready for review :)