Debug option not to delete ruby binaries from memfs/bin

[maxirmx]

(this is low-priority feature to support future development)

Add debug option not to delete ruby binaries from memfs/bin.
If there is a major change in deployment code it will very handy to have ruby binaries in there

[bradgessler]

I'm trying to debug several broken tebako builds and I find it very confusing that there's no bin/ruby somewhere when I run ./build/macos/arm64/bin/terminalwire-exec --tebako-extract. Where does Ruby end up inside the image? Adding this to the docs might help clarify these points.

[maxirmx]

There is an instance of Ruby that goes to bin/ruby. It is used to deploy the solution to be packaged.
The I delete it because this instance is not aware of memory filesystem

Tebako image is Ruby on its own. It is patched to use memfs and runs the packaged solution.
If you can share you project I will be happy to look at the issues

[bradgessler]

Interesting. What source could should I read to understand this? Is it the tebako-runtime gem? If I’m understanding what you’re saying, the compilation itself is Ruby, but patched to load everything from the dwarfs image that’s also somehow packed into the Ruby compilation? A link to the file where this happens would be helpful for me to learn how this works.

…

On Jan 14, 2025 at 14:00 -0800, Maxim Samsonov ***@***.***>, wrote: There is an instance of Ruby that goes to bin/ruby. It is used to deploy the solution to be packaged. The I delete it because this instance is not aware of memory filesystem Tebako image is Ruby on its own. It is patched to use memfs and runs the packaged solution. If you can share you project I will be happy to look at the issues — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[maxirmx]

Interesting. What source could should I read to understand this? Is it the tebako-runtime gem? If I’m understanding what you’re saying, the compilation itself is Ruby, but patched to load everything from the dwarfs image that’s also somehow packed into the Ruby compilation? A link to the file where this happens would be helpful for me to learn how this works.

CMakeLists.txt defines packaging sequence
Look for ExternalProject_Add(${RUBY_PRJ} and below

First comes the patch that is applied befor Ruby build
It is aimed to link Ruby statically including its extensions
This patch is needed because nobody supports static Ruby build after 2.5 (nobody except me, I guess)

PATCH_COMMAND ruby ${EXE}/tebako-packager pass1 ${OSTYPE_TXT} ${RUBY_SOURCE_DIR} ${FS_MOUNT_POINT} ${DATA_SRC_DIR} ${RUBY_VER}

There is an intermediate patch. I forgot why we needed it, but this one is small

COMMAND          ruby ${EXE}/tebako-packager pass1a ${RUBY_SOURCE_DIR}

After Ruby build there is

COMMAND          ${GNU_BASH} -c "ruby ${EXE}/tebako-packager pass2 ${OSTYPE_TXT} ${RUBY_SOURCE_DIR} ${DEPS_LIB_DIR} ${DATA_SRC_DIR} ${RUBY_STASH_DIR} ${RUBY_VER}"

This command does three things

1. It stashes Ruby executables (ruby itself, gem, bundler, etc) so they can be used to deploy solution that is packaged
2. It generates deploy.rb (see below) and several C files
3. It applies the final patch to Ruby source that makes it work with memfs

When tebako press is executed it runs deploy.rb (item 2 above) that takes Ruby executables from the stash (item 1 above); deploys solution to directory; builds memfs image from this directory and its subdirectories and links final image that includes finally patched Ruby (item 3 above), required libraries and memfs image.

On Windows there are some additional complications because Windows module does not have its own name and is identified by file name. Practically it means that native extensions that link back to ruby.exe won't run with tebako packages that have different names. During deploy we rebuild Ruby import library so that it refers to future tebako image name and then force rebuild native extensions for all gems of the solution. This procedure is also a part of deploy script.

In the very end there is finalize script

  add_custom_target(tebako COMMAND ruby ${EXE}/tebako-packager finalize ${OSTYPE_TXT} ${RUBY_SOURCE_DIR} ${APP_NAME} ${RUBY_VER} ${DEPS_BIN_DIR}/patchelf ${WITH_PATCHELF})

which strips debug information, renames and moves tebako package as applicable

[maxirmx]

To make it easier consider this procedure bootstrap of as cross-platform toolchain:

• we create native run-time (the first Ruby, after pass1)
• we create target run-time (the second Ruby, after pass2)
• we use native run-time to build the application for the target run-time
• we bundle the target run-time with the application