- User Since
- Mon, Jul 8, 3:30 PM (1 w, 5 d)
Seems it was decided to hold off on this until formation attacks are mechanically practical (I agree, but wasn't sure if this still needed review), since it would be unfair if units can be physically spread apart, but still get formation bonuses.
I haven't build- or run-tested this yet, but the diff looks conceptually OK.
Don't see the problem here. Whatever the % of users who are affected, at least some of them do play the game and have no idea how to fix this, as we don't document it anywhere.
Fri, Jul 19
Thu, Jul 18
Rebased to latest SVN
Wed, Jul 17
Tue, Jul 16
Ah, thanks! :) That makes sense then.
Why 3.0.4 in particular? I've built against 3.0.2 and it works (see also #2891, not sure which version the autobuilder currently uses -- it was 3.0.2 back then). We could simply say "the latest stable release", or something like that.
All I can think of are exceptions. What if an exception is thrown in CMapGeneratorWorker::Run()?
Remove some wxWidgets 2.x checks.
Mon, Jul 15
Trac ticket: #3920
It also has an entry on https://trac.wildfiregames.com/wiki/GameplayFeatureStatus
Sun, Jul 14
(about curly braces: I think this is one of the things where all current devs have sensible preferences/conventions, and for community contributors we can simply point them out during reviews. I realize that leaves uncertainty in the future, but as you say, there doesn't seem to be a "simple" rule. At least I never saw this being a problem in the codebase)
Reverts accidental comment from testing
I see no problem with this, but today is my first encounter with this aspect of the build, so I'll need a better grasp before reviewing.
Sat, Jul 13
I can give a little historical context here. Once upon a time VfsPath was:
typedef std::wstring VfsPath;
Fri, Jul 12
Thu, Jul 11
While I'm here:
Add --with-pic to GMP configure flags, fixing ld warning reported in #5489.
LIB_URL update was omitted from previous diff.
Wed, Jul 10
Also, requiring Homebrew to run a bundle (also an option to consider) breaks the Apple vision of apps as self-contained bundles. The 0A.D. bundle should rely only on what is inside it, and the standard macOS system libraries. That was always the design goal, and at least in the past, that was how it worked.
Another reason is that it allows building for other Apple platforms, including iOS. Even though we don't support that at all, I have tinkered with it in the past, and it helped substantially to have this infrastructure in place. Only a few differences needed between building for macOS and iOS.
So just to add onto this discussion, since myself and leper originally wrote this script.
Restore --enable-fat for GMP, and add to nettle as well.
Encountered this today while working on D2057. I mistakenly removed the flag, thinking it was only macOS "fat binaries" which are combined x86_64 and i386 archs.
Diff with full context
For a look at what disabled TCP fast open means, see https://gitlab.com/gnutls/gnutls/blob/master/lib/system/fastopen.c
Updates nettle to 3.5.1, gnutls to 3.6.8, and gloox to 1.0.22.
Fixes GnuTLS build by adding gmp to the LIBS var, otherwise it's a missing dependency in the configure script (they only add NETTLE_LIBS and HOGWEED_LIBS). NOTE: Upstream should include GMP_LIBS in the configure script.
GnuTLS 3.6.8 implements a new feature TCP Fast Open which requires a system function connectx, not available until OS X 10.11. Unfortunately GnuTLS doesn't currently support SDK-based builds, so the feature must either be enabled or disabled. I have chosen to disable it on macOS, as it's only an optional feature. We could certainly revisit an upstream patch to provide proper macOS SDK-based builds, or at least a build flag to disable TCPFO.