mesonbuild / wrapdb

New wrap requests
https://mesonbuild.com/Adding-new-projects-to-wrapdb.html
MIT License
69 stars 174 forks source link

Upstream OpenSSL wrap #1570

Open nazar-pc opened 1 week ago

nazar-pc commented 1 week ago

Conversation at https://github.com/openssl/openssl/issues/16812 finally converged on considering to add official (optional for now) Meson support upstream.

There are two major steps seeing there:

Essentially right now OpenSSL build system uses a non-trivial generator to figure out what sources and other things should be used depending on target platform, which causes challenges for end users trying to compile it, especialy when they don't want to rely on Perl.

By abstracting it in reusable way and generating during release process upstream, it would be much easier to pick pre-generated files by secondary build system like Meson.

Creating this issue downstream as this is where most of knowledgable engineers are who already maintain OpenSSL wrap.

I do not have the time to do this myself in the near term, but happy to collaborate with someone/help with review to make sure things are moving forward.

nirbheek commented 6 days ago

CC: @amyspark @benoit-pierre @glimchb @hrxi

amyspark commented 6 days ago

Hi @nazar-pc , I maintained this OpenSSL 1.1.x wrap while the branch was supported: https://github.com/amyspark/wrapdb/tree/amyspark/openssl

Is there any way I can help? What do you need?

nazar-pc commented 6 days ago

Check the first item listed to be done above, that is where we need to start.

The biggest challenge is that you can't simply compile OpenSSL. The first step is to run Perl scripts that generate assembly and other stuff specific for configured platform. We need to make OpenSSL generate those as part of CI such that it can be included in the official OpenSSL release. That way no one else will have to use Perl when they compile OpenSSL downstream.

Once that is done, we'll need to create a source of files to compile that both current OpenSSL build system could use to decide what to compile and Meson build system as well.

I think those are two immediate next steps, but they are very non-trivial and will require upstream buy-in.

amyspark commented 6 days ago

We need to make OpenSSL generate those as part of CI such that it can be included in the official OpenSSL release

This should be covered by porting https://github.com/nodejs/node/commits/v20.x/deps/openssl 's bindings generator to OpenSSL itself. My wrap was able to drive this generator from within Meson, so I think we could use that as a start.

nazar-pc commented 6 days ago

Upstream wrap also is able to do that. However, note that for it to be upstreamable we need to ensure to cover different scenarios. There are various OpenSSL options that can be used to tweak its behavior and they need to be somehow exposed. Ideally we'd generate sources for the platform once and control the rest with defines.

Also I would recommend to focus on x86-64 Linux/macOS/Windows first and ignore other platforms for now to make diff easier to review (maybe add aarch64 if you feel adventurous). Once approach is agreed with upstream and initial code lands, code generation can be expanded to other platforms. Upstream maintainers may have a different opinion on this, but this is how I would approach it to reduce friction.