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?
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.
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.
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.
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.
The source code zip is just a zipped up full git checkout of the oolite repository at the 1.92 tag, including all submodules. The manual interventions are the deletion of the .git folder (not needed for the purposes of this zip) and the addition of the manifest file in the Resources folder. Everything else is exactly as it currently stands in github.
I would suggest using the 1.92 source zip as reference. There are no typos there, it is what's in the source at this moment.
