Impact of new builds

[hiran]

I am thinking about how to simplify the build so that new developers can understand it easily. I'm also considering how to have the version come from the GitHub release tag into the build rather than having to be hard coded in different places. So I need to get an understanding of what is being used and how.

I am striving for the same and thus open to discuss. The Github flows you improved were introduced by me to relieve developers from building manually on different platforms. However currently there is impact.

Could we restore functionality and then discuss how to simplify?

[Lone_Wolf]

I am preparing a zipped 1.92 source code tarball and am going to add the manifest file (the one normally created during build) inside it. Resources will be included too. Hopefully this will help with the issue.

Edit: Uploaded source code tarball https://github.com/OoliteProject/oolite ... e-1.92.zip
Manifest file can be found inside the Resources folder.

Content of the Resources folder in that file :

Code: Select all

AIs
Binary
Config
Scenarios
Scripts
Shaders
AIReference.html
InfoPlist.strings
manifest.plist
oolite-document.icns
oolite-expansion-document.icns
oolite-icon.icns  
README.TXT

Hiran, is that enough to create the expansion catalog from ?

[hiran]

I am preparing a zipped 1.92 source code tarball and am going to add the manifest file (the one normally created during build) inside it. Resources will be included too. Hopefully this will help with the issue.

Edit: Uploaded source code tarball https://github.com/OoliteProject/oolite ... e-1.92.zip
Manifest file can be found inside the Resources folder.

Content of the Resources folder in that file :

Code: Select all

AIs
Binary
Config
Scenarios
Scripts
Shaders
AIReference.html
InfoPlist.strings
manifest.plist
oolite-document.icns
oolite-expansion-document.icns
oolite-icon.icns  
README.TXT

Hiran, is that enough to create the expansion catalog from ?

That's what I was asking for, yes. It does not prevent that I have to make adaptions as the structure is not identical to the MacOS build I had used before - but that is no showstopper.

I'd like the file to be autogenerated so we can be sure it always exists and has the same structure. The name of the file is not important either - but calling it source would imply it is a dump of the repository where some of the content is not part of the repo. From my desk this looks misleading. But as said, it's not that important.

[hiran]

I downloaded and inspected the new file oolite-1.92.zip. It contains the required files. It also contains traces of having been handcrafted.

With the oolite-1.90.zip I used to processed the path /Oolite.app/Contents/Resources/
With the oolite-1.92.zip I now need to process the path /oolite.app/Contents/Resources/

As the indexing runs on a Linux build machine the case matters. I would need to know whether this is a typo that will be corrected or if it is the future directory structure and thus the indexing process needs to access the new location.
And such little differences are what can break automation completly - the reason why I'd like to have this new file produced by the build process automatically.