Oolite Bulletins

another_commander wrote: ↑Mon Jan 10, 2022 3:25 pm

I believe your Windows build workflow references also your own oolite repository for downloading the code, so I guess this will have to be changed to point to the official repo. I could be wrong though, but in any case all these are things that can be adjusted further down the road.

Regarding the dev environment, I would suggest removing the folders Mingw32_100300, Mingw64_100300, mingw32_710 and mingw64_710. They add huge volume to the data the workflow tries to download and they are not used at all.

another_commander wrote: ↑Mon Jan 10, 2022 3:25 pm

I believe your Windows build workflow references also your own oolite repository for downloading the code, so I guess this will have to be changed to point to the official repo. I could be wrong though, but in any case all these are things that can be adjusted further down the road.

another_commander wrote: ↑Mon Jan 10, 2022 2:53 pm

hiran wrote: ↑Mon Jan 10, 2022 2:27 pm

@Another_commander: I likely need not only access to the oolite repository but the OoliteProject. After all it is several repositories that need to work together.

I will be sending you an invitation to join OoliteProject soon. I think it might be worth considering importing your changes to the repository only once we confirm that they work though, i.e. start by importing the (already verified) Windows build workflow changes, continue with Mac or Linux once we have confirmation that they work too etc. Note that some further changes will be required for the Windows workflow, as it contains references to your own fork - those should probably be switched over to the Oolite repository.

Anyway, I'll let you handle it as you see fit. Just throwing ideas at this point.

hiran wrote: ↑Mon Jan 10, 2022 9:03 pm

another_commander wrote: ↑Mon Jan 10, 2022 2:53 pm

hiran wrote: ↑Mon Jan 10, 2022 2:27 pm

@Another_commander: I likely need not only access to the oolite repository but the OoliteProject. After all it is several repositories that need to work together.

I will be sending you an invitation to join OoliteProject soon. I think it might be worth considering importing your changes to the repository only once we confirm that they work though, i.e. start by importing the (already verified) Windows build workflow changes, continue with Mac or Linux once we have confirmation that they work too etc. Note that some further changes will be required for the Windows workflow, as it contains references to your own fork - those should probably be switched over to the Oolite repository.

Anyway, I'll let you handle it as you see fit. Just throwing ideas at this point.

I just noticed you already invited me. So I created the workflow file. But without the mentioned repository the build fails (unless I introduce that reference to my private project). And as it seems I have no privileges to create a new repository in OoliteProject.

https://github.com/OoliteProject/oolite ... focus=true

another_commander wrote: ↑Sun Jan 16, 2022 7:12 pm

I would prefer to have something that builds and runs before getting it over to the official master branch. If it doesn't run, I would suggest to investigate why it doesn't and fix it first.

hiran wrote: ↑Sun Jan 16, 2022 7:30 pm

another_commander wrote: ↑Sun Jan 16, 2022 7:12 pm

I would prefer to have something that builds and runs before getting it over to the official master branch. If it doesn't run, I would suggest to investigate why it doesn't and fix it first.

Then we need Mac users actually try that build.

Commander_X tried what he built on his machine and just got error messages before the thing would shutdown.
I had surprisingly add libjpeg (check my Github Action) and apply a patch to the seamonkey repository (see my clone).
Unfortunately I am not sure how to get closer to your requirement without touching the source code - and as soon as do that we need to validate the other OSes builds in parallel.

Advice is welcome.

Cholmondely wrote: ↑Sun Jan 16, 2022 10:09 pm

hiran wrote: ↑Sun Jan 16, 2022 7:30 pm

Then we need Mac users actually try that build.

Commander_X tried what he built on his machine and just got error messages before the thing would shutdown.
I had surprisingly add libjpeg (check my Github Action) and apply a patch to the seamonkey repository (see my clone).
Unfortunately I am not sure how to get closer to your requirement without touching the source code - and as soon as do that we need to validate the other OSes builds in parallel.

Advice is welcome.

I can download and run - but know nothing about any of this stuff: Development Environment (Xcode)

The supported development environment for Oolite trunk is Xcode 4.5 or later under Mac OS X 10.7.4 or 10.8. At the time of writing, Xcode 4.2–4.4 are likely to work, while earlier versions such as 3.2.6 running under Mac OS X 10.6 or later will only work after some additional changes, and are no longer supported. Xcode 4 is available for free from the Mac App Store.

Earlier versions of Oolite, including the 1.76-maintenace branch, require Xcode 3.2.6, even under Mac OS X 10.7 or 10.8. For more information, see this earlier version of this page.

You will also require the Subversion version control tool; an up-to-date binary is available here, or in the optional Xcode command line tools package. To download the command line tools package, select Open Developer Tool→More Developer Tools… from the Xcode menu within Xcode.

hiran wrote: ↑Mon Jan 17, 2022 6:15 am

Cholmondely wrote: ↑Sun Jan 16, 2022 10:09 pm

hiran wrote: ↑Sun Jan 16, 2022 7:30 pm

Then we need Mac users actually try that build.

Commander_X tried what he built on his machine and just got error messages before the thing would shutdown.
I had surprisingly add libjpeg (check my Github Action) and apply a patch to the seamonkey repository (see my clone).
Unfortunately I am not sure how to get closer to your requirement without touching the source code - and as soon as do that we need to validate the other OSes builds in parallel.

Advice is welcome.

I can download and run - but know nothing about any of this stuff: Development Environment (Xcode)

The supported development environment for Oolite trunk is Xcode 4.5 or later under Mac OS X 10.7.4 or 10.8. At the time of writing, Xcode 4.2–4.4 are likely to work, while earlier versions such as 3.2.6 running under Mac OS X 10.6 or later will only work after some additional changes, and are no longer supported. Xcode 4 is available for free from the Mac App Store.

Earlier versions of Oolite, including the 1.76-maintenace branch, require Xcode 3.2.6, even under Mac OS X 10.7 or 10.8. For more information, see this earlier version of this page.

You will also require the Subversion version control tool; an up-to-date binary is available here, or in the optional Xcode command line tools package. To download the command line tools package, select Open Developer Tool→More Developer Tools… from the Xcode menu within Xcode.

Hang on!
You can download an run? You mean Oolite does not crash and you can play the game? That would be something!

Then there is a second question about 'the stuff': Where did you get that from? The logfile? Some error message or popup messagebox at the beginning of the game? Or just as content of one of the files inside the ZIP file?

Cholmondely wrote: ↑Mon Jan 17, 2022 8:07 am

Apologies: I can try to download, I can try to run. Have not done anythng yet.

another_commander wrote: ↑Fri Jan 21, 2022 12:52 pm

@hiran: Please check my comment here: https://github.com/OoliteProject/oolite ... 1018476874
This is something we may need to consider if we are to have more than one builds generated from within the Oolite repository.

Edit: Also, the source code has been packaged in the Linux result. This will need some clean up.