Changing Oolite...

[hiran]

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.

Confirmed. The build still works with the named directories removed.

[hiran]

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.

Your claim may be valid, yet I do not find any such reference in build-windows.yml. Yes, there is a reference to HiranChaudhuri/oolite-windows-build-env, but that is the one repo which does not exist in OoliteProject and needs to be created. The Oolite checkout just refers to the 'current' repository, which will also work as intended when added to OoliteProject/oolite.

If you check the submodules at .gitmodules you can see I changed them all to directly refer to OoliteProject.

So from my POV there would be nothing pointing to my repo/project once we import the necessary stuff.

[hiran]

@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

[hiran]

@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

Thank you for setting up that repository. I can see the workflows already worked successfully.
Let me know if you feel comfortable that I remove HiranChaudhuri/oolite-windows-build-env again.

[hiran]

I am trying to get Oolite builds for Mac running. I have no Mac, never had one and definitely never built any Objective C project, not to talk about Oolite.
The most current Github master branch produced lots of warnings which i removed, then it was missing libpng which I added.
Now I get some errors like this:

Code: Select all

error: meaningless 'volatile' on asm outside function

See also https://github.com/HiranChaudhuri/oolit ... focus=true


I'm afraid my wisdom is not sufficient to decide how to get around this. Should I change the compiler? Should I change the code?
Any help appreciated.

[hiran]

@another_commander:
We achieved some kind of Mac build with questionable quality. To the very least it is repeatable.
Do you think it makes sense to integrate that into the official repository?

[another_commander]

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]

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]

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.

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]

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]

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?

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

[hiran]

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

Please download and run the game. I'd be very much interested how far you get.
If you write down what you perceive that should be good enough for someone to take it further.

[hiran]

One little step further, we can compile for Linux now.
This build contains too many files and has not been tested in any way. But it exists!

https://github.com/HiranChaudhuri/oolite/releases

[another_commander]

@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.

[hiran]

@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.

Full ack! My experiment is still running in https://github.com/HiranChaudhuri/Oolit ... r/releases