Refactoring into multiple files / parts

[Largo]

Most of the action happens in the ocran file. I think it would be nice to split this up, so it would be easier to understand.
I think we can make ocran work on OSX and Linux, so we should move the windows specific parts into separate files.

Split up:

• innosetup / stub
• Classes into own files

https://github.com/Largo/ocran/blob/master/bin/ocran

[shinokaro]

I agree with the approach of splitting the files.
The builder class should be a separate class and instance for each build target.

[shinokaro]

I would like to share more details about the problem, including the technical background and the challenges we are facing.

Technical Background and Current Challenges

The implementation of Stub, inherited from OCRAN's predecessor OCRA, had an old bug where it ignored errors during the working directory change. Our refactoring work has made these errors reportable, uncovering previously hidden issues.

Specifically, Stub was originally designed to expand files into a temporary directory and execute them, which is not suitable for the operation in the installation directory used by the InnoSetup process. The behavior of Stub in the installation directory fails to meet this expectation, resulting in a failure to change the working directory.

Proposal and Work Plan

Based on these findings, I propose to proceed with refactoring InnoSetupBuilder to achieve an installer creation process that does not depend on Stub. This approach will make the installation process more robust and reliable, allowing users to install and execute the application smoothly.

With these changes, we can resolve the issues related to working directory changes, improving the reliability and usability of the entire system.
@Largo

[shinokaro]

In commit 8d291f9d, I implemented the separation of OcranBuilder into StubBuilder and InnoSetupBuilder.

[shinokaro]

I have some ideas about making OCRAN work on OSX and Linux. Currently, OCRAN uses stub.exe to create self-extracting files, but this stub.exe only operates in the Windows environment. A different approach is needed to make the OCRAN package function on multiple platforms.

Here are some proposed solutions:

• Modify the source code of stub.exe to be multi-platform compatible.
• Introduce self-extracting executable code that works on OSX and Linux from external sources, or follow a process similar to InnoSetup where the user prepares it.
• Create distribution packages specific to each operating system.
• Package in archive file formats, attaching a startup shell script generated by OCRAN.

[Largo]

As a first step, can we first have code that will make a directory with the source code and the ruby binaries + dlls / dlyb / so files? If we have that working on one plattform it will be a lot easier to continue. So for now we can leave the stub for just windows. For that we continue to refactor the code.

But I agree on the solutions! Thanks!

[shinokaro]

So for now we can leave the stub for just Windows.

Making the stub portable across multiple platforms is challenging at this time. Moreover, in Windows environments, users require the .exe format. We will be adding several package builders, but for the sake of OCRAN's autonomy, the stub will be maintained.

[shinokaro]

As a first step, can we first have code that will make a directory with the source code and the ruby binaries + dlls / dlyb / so files?

I can work on this. One personal motivation of mine has been to create ZIP packages, which is a major distribution format in Japan's Windows environment. Importantly,
we also need to output information necessary for script execution. This information should include environment variables (including OCRAN_EXECUTABLE) and command options at the time of script execution.

[Largo]

Yes, zip would be great! As you know, it's already possible to create a folder. Feel free to make a argument that will automically zip that folder.

In the future it would be nice if this folder can be extended with ruby for other OS.
Probably you will still need to run ocran on other OS, but it should be easy to change the source.

The zipfile should also be offered as PKZIP self extracting option.

Btw. You might find lib cosmopolitan interesting justine.lol/ape.html

[shinokaro]

I have completed the refactoring work. It took me five full months to break down what was essentially a massive, uncut gem. As a result, all we have are split files. This means that not only does it fail to resolve any existing issues, it also doesn't add any new features. However, I believe that this has laid the groundwork for what comes next—OCRAN.

[Largo]

Really cool. Thanks! I'm sure this will mean it will be a lot easier for others to help us to improve OCRAN. My vision is for OCRAN to help Ruby to become a good option for crossplattform apps!

[shinokaro]

#26

I have created a new issue to discuss the recent proposals mentioned here. The ocran.rb has been split into separate files, and this change is permanent. Therefore, we can close this issue.