Using in vendored mode with additional internal extensions
I want to start using the project in vendored mode and add our own custom PHP extension. This means we should add additional 'sources' and 'ext' items to have a streamlined process with the project.
Is this already possible to achief? If so could you guide me a little or point me in a direction?
After digging around I think we need to add additional configuration into the BuilderPovider instance. I coulnd't find a proper way yet to add the addional configuration yet.
Do you want to compile your custom extensions in statically or dynamically?
If you mean adding an extension, you can fork the project and modify the configuration file to add it.
Currently there is no other way to add extensions outside of src, because there is no ABI specifically designed for vendor mode or spc mode.
I think the simplest solution here would be to use the spc-gnu-docker and load the extensions dynamically. Requires zero code changes to static-php-cli.
Statically would be preferable, but currently I have working version dynamically. Both is fine at this moment. Forking the project is currently the way I have done it as well, but found it very inconvinient keeping the fork up-to-date with upstream changes. I would like to have composer resolve that part for me instead of my own fork.
Let me see if i can conjure up some very minimalisc changes to "extend" current configuration.
I was thinking about something in these lines:
- Use the project in "vendor" mode, via
composer require crazywhalecc/static-php-cli. - As explained in the vendor library mode documentation.
- Load up customizations ontop of the generated builder instance.
It's a possible approach, I'll think about it.
I have always been very conservative about APIs. It would be difficult to keep the API unchanged if some changes were made in the future.
When I was designing 2.0.0 in the early days, I planned to use a process-oriented single-file approach to declare extensions and libraries, which might be something like this:
<?php
$lib = spc_register_library('testlib', config: ['static-libs-unix' => ['libtestlib.a']], source: ['type' => 'local', 'path' => 'testlib']);
$lib->onLinuxBuild(function ($lib) {
shell()->cd($lib->getSourceDir())
->exec('./configure --enable-static --disable-shared --prefix=' . BUILD_ROOT_PATH)
->exec('make -j' . $lib->getBuilder()->concurrency)
->exec('make install');
});
$lib->onDarwinBuild(function ($lib) {
});
$extension = spc_register_extension('mybook', config: ['lib-depends' => 'testlib'], source: ['type' => 'local', 'path' => 'mybook']);
$extension->setUnixConfigureArg('--enable-mybook');
$extension->setWindowsConfigureArg('--enable-mybook');
$extension->onPatchBeforeMake(function ($extension) {
/** @var \SPC\builder\unix\Extension $extension */
shell()->cd($extension->getSourceDir())
->exec('patch -p1 < ./mybook.patch');
});
That's a very similair approach what I was thinking off as well. builder like approach, I like it!
I think I am able to manage to create something with the current setup, with minimal changes. Will push soon! Got some other stuff to work on before I can finish it.
I haved pushed a PR and created a repository to show off, the way I was able to make a custom project without entirely forking: https://github.com/crazywhalecc/static-php-cli/pull/691
The conclusion is that I will fully implement the vendor mode in the near future, but before that I would like to implement the development part of skeleton generation and improve the documentation. This will help us use the vendor mode more conveniently. This may be a relatively large project, requiring the organization of all internal APIs and callable methods. So I decided to approch in 3.0.
Since static-php supports static builds of many libraries, we will also be able to reuse these dependencies in vendor mode for building other non-php static binaries.