Move FFI functions to a separate class

[kleisauke]

This makes it easier to check whether php-vips is based on FFI or php-vips-ext at runtime.

<?php

require __DIR__ . '/vendor/autoload.php';

use Jcupitt\Vips\FFI;

echo \class_exists(FFI::class) ? "php-vips based on FFI" : "php-vips based on php-vips-ext";

/cc @chregu since these checks needs to be adjusted after this PR:
https://github.com/rokka-io/imagine-vips/blob/a70db9c3fc678fcb3b70c99682e15ad45325f27f/lib/Imagine/Vips/Imagine.php#L53
https://github.com/rokka-io/imagine-vips/blob/a70db9c3fc678fcb3b70c99682e15ad45325f27f/lib/Imagine/Vips/Imagine.php#L208

[kleisauke]

Oh wait, the above mentioned checks need to be modified anyway, because the ffi() function has been renamed to vips() in d8d0d63. Sorry about that.

[kleisauke]

... perhaps we need to find another name for this new class, since the FFI class is already used by the FFI extension?

[chregu]

The FFI class in this case is namespaced, so that shouldn't be an issue?

[chregu]

The problem in imagine is more that there is already 2.0.3 released, so I need to check for all cases. (Or just exclude 2.0.0 - 2.0.3 in composer.json, which shouldn't be an issue to do, because I don't think anyone needs <= 2.0.3 but not > 2.0.3)
But I guess it would be easier for this check, if the next version would be just 2.1.0 and not 2.0.4

[jcupitt]

Ooop, I'd forgotten this PR, sorry. Should we fix this up and release as 2.1?

It might be useful to get something like this patch in too (look for libvips in a few standard locations): #140 (comment)

[kleisauke]

No worries, it fell off my radar too. I'll rebase and update for inclusion in version 2.1.

It might be useful to get something like this patch in too (look for libvips in a few standard locations): #140 (comment)

Ah, I think it's due to Apple's security restrictions, where DYLD_* environment variables are purged when starting protected processes - see: Homebrew/brew#13481 (comment).

Perhaps we could reinstate the removed VIPSHOME logic in commit 387f4c1 instead? Allowing macOS M1 users to run php-vips programs using:

export VIPSHOME=$(brew --prefix vips)

The FFI class in this case is namespaced, so that shouldn't be an issue?

Indeed, that shouldn't be an issue (I hadn't been working on any PHP-related code lately).

[kleisauke]

... included that patch with some modifications in commit 0b29a6e, but let me know if you prefer that in a separate PR.

[jcupitt]

That all looks great! I'll make 2.1.

[chregu]

Just for the record. I updated https://github.com/rokka-io/imagine-vips with those additions (and excluded php-vips 2.0 in composer.json to make life easier in the code)

[kleisauke]

@jcupitt v2.1.0 was tagged on commit c46db55, but that commit is not present in the master branch. Probably this is due to git push --tags.

[jcupitt]

Ack I'm always doing that, the behaviour is so confusing, sorry.