Skip to content

Using in vendored mode with additional internal extensions #687

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
yoramdelangen opened this issue Mar 31, 2025 · 8 comments
Open

Using in vendored mode with additional internal extensions #687

yoramdelangen opened this issue Mar 31, 2025 · 8 comments
Assignees
Labels
kind/extension Issues related to extensions new feature New feature or request

Comments

@yoramdelangen
Copy link
Contributor

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.

@yoramdelangen yoramdelangen added the question Further information is requested label Mar 31, 2025
@crazywhalecc crazywhalecc added the kind/extension Issues related to extensions label Mar 31, 2025
@crazywhalecc crazywhalecc self-assigned this Mar 31, 2025
@DubbleClick
Copy link
Collaborator

Do you want to compile your custom extensions in statically or dynamically?

@crazywhalecc
Copy link
Owner

crazywhalecc commented Mar 31, 2025

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.

@DubbleClick
Copy link
Collaborator

DubbleClick commented Mar 31, 2025

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.

@yoramdelangen
Copy link
Contributor Author

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.

@crazywhalecc
Copy link
Owner

It's a possible approach, I'll think about it.

@crazywhalecc
Copy link
Owner

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');
});

@crazywhalecc crazywhalecc added wontfix This will not be worked on new feature New feature or request and removed wontfix This will not be worked on question Further information is requested labels Apr 2, 2025
@yoramdelangen
Copy link
Contributor Author

yoramdelangen commented Apr 2, 2025

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.

@yoramdelangen
Copy link
Contributor Author

yoramdelangen commented Apr 4, 2025

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: #691

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/extension Issues related to extensions new feature New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants