Release process documentation?

[chrisballinger]

I've had trouble piecing together the various build products. Is this process documented anywhere? Ideally I want to automate nightly builds for Engines, Wrappers and Winery.

[Gcenx]

@chrisballinger

"Wineskin Winery.app" runs just fine after being built, only needs to be compressed if it's to be added to the server for downloading directly from within the app and then update the {server}/Wrapper/NewestVersion.txt
{server}/Wrapper/WineskinWinery.app.tar.7z
The above is basically the same for everything else that needs to be hosted, engines text file just includes a list of available engines to download.
Here I have a working WineskinServer, fork then swap out the masterwrapper and Winery files with your own to get started easily.

Wineskin.app needs to be placed inside.

wineskin-{version master wrapper version number}.app
drive_c symlink to "Contents/Resources/drive_c"
Contents

Contents Folder>

Frameworks
MacOS
Resources {included in the provided link)
Info.plist {included in the provided link} (includes the entries from my changes)

Frameworks Contents>

Frameworks>{needed dylibs} (I included current ones in the link provided)
Frameworks> {add ObjectiveC_Extension.framework}
Frameworks>WSX11Prefs.plist (included in the provided link)
Frameworks>bin (included in the provided link)

MacOS Contents>

WineskinLancher {current version from project}
WineskinX11 (included in the provided link)

Wrapper Template

[chrisballinger]

Thanks! It would be great if we could figure out how to bundle the app in such a way where the "Wineskin Winery.app" bundle includes the latest "Wineskin.app" wrapper template, and at least one working Engine.

Also is there any way to run Wineskin.app or WineskinLauncher in the Xcode debugger? They normally want to live inside a wrapper.

[Gcenx]

I don't know if including it inside "Wineskin Winery.app" is a good idea.
That would mean needing to update "Wineskin Winery.app" a lot more to ensure future compatibility with macOS versions. But I can see the appeal "winebottler" did something along those lines.

Running "Wineskin.app" inside xcode debugger I have no clue how @vitor251093 might be better for answering that.

WineskinLauncher same thing, but I assume as long as you have the needed ObjectiveC extension I don't why it wouldn't be possible since you can pass commands directly to it. WSS- are the main functions.

[vitor251093]

Thanks! It would be great if we could figure out how to bundle the app in such a way where the "Wineskin Winery.app" bundle includes the latest "Wineskin.app" wrapper template, and at least one working Engine.

I don't know if including it inside "Wineskin Winery.app" is a good idea.
That would mean needing to update "Wineskin Winery.app" a lot more to ensure future compatibility with macOS versions. But I can see the appeal "winebottler" did something along those lines.

I agree with @Gcenx . Keeping them separated makes we capable of releasing updates separately, and that's an advantage. While it would be interesting to release a package once in a while with an stable version of all of them, once the three of them get stable versions, they shouldn't be bonded together.

Also is there any way to run Wineskin.app or WineskinLauncher in the Xcode debugger? They normally want to live inside a wrapper.

Running "Wineskin.app" inside xcode debugger I have no clue how @vitor251093 might be better for answering that.

I usually build them in Debug mode, move to the insides of a wrapper, and then, if I want logs, I run the binaries using the terminal. It certainly isn't the best method to do, but that's what I've done during my tests xD

Xcode can be configured to send the result of the build to a wrapper so you can run them, however it would require a wrapper with a specific name in a specific location. Since that changes from environment to environment, I decided to do this manual method instead of doing that.

Also, a reminder: while Wineskin.app can be build in Release mode, WineskinLauncher can't. The reason for that is simple: when an app is build for release today, it considers its Info.plist has unique, and gives the Info.plist an identifier of the binary. Summarising, if you run WineskinLauncher in Release mode, you can't change the Info.plist file of the wrapper, and that's a real problem for Wineskin wrappers.

[chrisballinger]

We can likely set up an Xcode build target that moves everything into the right place.

Even if we don't ship production builds this way, it would be great to remove manual steps from the debugging workflow.

[vitor251093]

Yeah, is the kind of thing that saves lots of time on term.

[chrisballinger]

On the road toward automating the builds, I made a tool to automate the creation of Engines: https://github.com/WineskinCommunity/WineskinEngineBuilder

[vitor251093]

Awesome! :D

[Gcenx]

Nice the updated EngineBuild bash scripts might be redundant now.

Are you later adding the ability to compile from source also? It's needed for making CX engines.

[chrisballinger]

@Gcenx Haven't added a compile from source option yet, but have some of the scaffolding for it in there. Would you mind adding any documentation you have on building engines from scratch to this issue? WineskinCommunity/WineskinEngineBuilder#1

[Gcenx]

@chrisballinger Sure I just need to dig it up from my backup, I could also 7zip the EngineBuild scripts I have along with everything for building Engines on 10.13.

Those are modified bash scripts based on what doh123 made but it works I built CX17.5.0 & CX17.5.0 64bit using them.

[niveuseverto]

@Gcenx can lend a hand here, if you restore Wineskin launcher template

[Gcenx]

@Gcenx can lend a hand here, if you restore Wineskin launcher template

@niveuseverto if I have time tonight I can replace that with a newer mini dylib template.

If your only interested in building the project to use with official winehq wine builds then you can use the prebuilt development then you can just grab WineskinWinery.app.tar.7z from the Winery folder.
That is built using EngineRepacking2 branch it just reads from the linked GitHub for EngineList.txt etc

[niveuseverto]

I'm interested in this as a part of @foesmm to provide ability to create stable wineskins for supported gamebryo games, so building/packaging from source (including wine) is desirable

[Gcenx]

I'm interested in this as a part of @foesmm to provide ability to create stable wineskins for supported gamebryo games, so building/packaging from source (including wine) is desirable

That makes sense then, just remember you need to use the Winery version from the project to make wrappers as the "official" one will fail due to the structure changes as I explained above.

Here is an updated Wrapper template , I did not shrink it down to a mini dylib subset as you may need some of those so I left them all in. That template will allow the use of doh123 engines / Winehq engines / PortingKit engines.
Copy the WineskinLauncher into "Contents/MacOS" and Wineskin.app into the same location as the "drive_c" symlink.
Also add in the compiled "ObjectiveC_Extension.framework" into the templates "Frameworks" folder
If you have any issues replace libfreetype.6.dylib from XQuartz 2.7.11 Updated the template with libfreetype.6.dylib from XQuartz 2.7.11

For compiling engines I have encountered some issues with custom built wine versions when using Clang, the only stable compiles have been cross-compiled using the Official Winehq build system, you can use Ubuntu Bionic as the system base. I have not have enough free-time to setup a docker image for this.
It should possible to build using gcc6 or above on macOS, gcc5.2 and lower cause other problems for wine compiles.