Ben Phegan

@hyperion - unfortunately it appears that the source files referenced for Spidermonkey in https://code.wildfiregames.com/D5002 no longer exist. For reference, the build script will attempt to download https://github.com/wraitii/spidermonkey-tarballs/releases/download/mozjs-102.12.0/mozjs-102.12.0.tar.xz which does not exist. @wraitii - is there any documentation on how you grab and upload this file? Is there a way to replace this with a source reference?

@hyperion you mean Mac OS X 10.12? Sierra? That hasn't had a security patch since 2019 though, right? I have not tried anything that old, and I can say for sure that the later versions do not work for me out of the box due to changes in the default compilers/linkers. Will try with the updated SpiderMonkey patch, but so I am clear, what is the future of that patch? Is it likely to merge? If so, what sort of timeframe? I am finding it particularly difficult to track the future state of the project based on the state of the patches/issues. I am already automating a _bunch_ of patches to get this far, and it is far from ideal. Some of the patches I am applying are quite old. Like, three years as a patch diff sitting on an issue. What is the governance around these?

@vladislavbelov is the required MacOS/SDK version documented anywhere? I can always drop a machine back to an early MacOS and SDK to get building, or even just use a VM. Also, can confirm that it does not work on later MacOS and SDK/toolchain (lots of breakage). I have a branch locally tracking required changes for when you are looking at this.

Is 0-AD still buildable on modern Mac software/hardware? Does anyone have this working? I would love to replicate, and I am happy to update documentation/build scripts/patches if necessary.

Just as an update to this, I have managed to get a lot of the build working via a lot of patching. The sticking point is Spidermonkey. I am using the following config: MacOS: 14.0 Xcode: 15.0 Hardware: MacBookPro18,1 I have also tried building on an Intel Mac running 12.7. Neither works out of the box, and so far neither are successful at all. To get any further than the error above an an M1 requires linking with `lld` instead of the default `ld`, installing the LLVM package via `brew install llvm` and a bunch of mods to various build files. It is just not supported as far as I can tell. Is there anyone who _successfully_ builds on Mac _currently_? If so, would love to know what their config looks like? At the moment, I do not want to go too far down the path of fixing these issues as to be honest I cannot see a reasonable way forward getting patches in place if no-one is building on Mac.

Having enjoyed the game a lot, I recently thought that I would look to jump in and start helping by picking up some issues and seeing if I could fix them. 0-AD is a fantastic game, and the amount of work that has gone into it is amazing. However, there are a few friction points that may not be obvious to those that have been working with the project for a while. Personally I cannot wait until decisions around git hosting and development workflow changes (many of which are impacted by work associated with this thread) are implemented. Some thoughts about the current process and the suggested changes from someone new to the project: Having read through this thread, I understand the requirement to self host. Gitea or https://forgejo.org are great alternatives, but there has to be a realisation that to attract and enable new developers the Github model is the "normal" workflow for your target future developers (me included). Any deviation will become a point of friction. And one more point to make on this...if GitHub were to disappear or become onerous from licensing point of view, due to its size and ubiquity transferring to another service would most likely be both automated and trivial for the services that are not already interoperable such as git (ie issue tracking, pages, CI etc). This, from my point of view, makes it a negligible and easily mitigated risk. The current approach (SVN, patch files on issues, trac etc) is such a _massive_ issue to attract and enable new developers. Many developers have _never_ used svn. They have spent their entire careers using Git and Github, PRs are normal, branching and forks are "the only way". I am originally from the rcs/cvs generation and have spent a lot of years as a build engineer, and it was jarring to have to find and download a bunch of patch files attached to Trac issues and apply them in an attempt to even build the code. PRs, a consistent git-based branching mechanism, issues alongside the code (not Trac) and frequent merges/CI builds would make things significantly simpler. git-lfs, from my experience, can solve a bunch of the issues with large files. It is mainstream, can be self hosted, and is seriously mature now. It really can be a significant part of the solution. The build process is problematic. If you can build it in CI, it should be possible to replicate locally...and ideally CI is a _very_ slim shim around default developer workflow. Jenkins is a great choice, but it would be awesome if developers could model a build environment on the CI process really easily. It should be (almost) as simple as checkout and run single file. Moving this front and centre to development process would again simplify the onboarding process. I have been trying to build 0-ad on multiple OSs (mainly Mac) for the best part of a week, and still hitting issues that require patches or workarounds. Really keen on seeing the project become much more accessible to other developers, and happy to help where I can!

Thanks @phosit hopefully they can help. I noticed that there are Dockerfiles that are used for Jenkins, but there is no specific singular Dockerfile approach to developing under Linux. Are most of the devs using Windows? I could transition to a Linux dev process and use Docker if there was a reasonable cross compilation approach (not sure that this is currently possible though).

Hi, I am trying to get 0-AD building on an M1 Mac running Ventura 13.6. I have had to apply various patches (D2573, D5092, D5093) as well as two additional patches, one for vorbis (no issue raised yet but related to compiler flags) and Spidermonkey `ld` issue (current version on Mac does not have --version as an ld parameter). However, despite all this I am still getting a compilation failure on Spidermonkey. It is probably some local variance that I have not accounted for. The issue is when running `./build-osx-libs.sh` when it gets to Spidermonkey. As part of the configure I get this: checking for 64-bit OS... yes checking for linker... DEBUG: Executing: `/usr/bin/clang -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -std=gnu99 --target=arm64-apple-darwin -Wl,-v` ERROR: Failed to find a linker ERROR: Error building spidermonkey Previous to my patch it was failing due to passing `-Wl,--version` which is incompatible. However now, if I rerun the command with `-v` I get the following: ➜ osx git:(m1) ✗ /usr/bin/clang -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -std=gnu99 --target=arm64-apple-darwin -Wl,-v -v Apple clang version 15.0.0 (clang-1500.0.40.1) Target: arm64-apple-darwin Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin "/Library/Developer/CommandLineTools/usr/bin/ld" -demangle -lto_library /Library/Developer/CommandLineTools/usr/lib/libLTO.dylib -dynamic -arch arm64 -platform_version macos 13.0.0 14.0 -syslibroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -o a.out -v -lSystem /Library/Developer/CommandLineTools/usr/lib/clang/15.0.0/lib/darwin/libclang_rt.osx.a @(#)PROGRAM:ld PROJECT:dyld-1015.7 BUILD 18:48:48 Aug 22 2023 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29) TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3) Library search paths: Framework search paths: ld: Undefined symbols: _main, referenced from: <initial-undefines> I have not been able to find many hits on this error that seem relevant. My guess is it is something to do with my compiler/SDK install. Does anyone have a working M1 build machine that would be happy to help with troubleshooting? Thanks! Ben