Build failure - The Moirai have given mortals hearts that can endure.

Link to build: https://jenkins.wildfiregames.com/job/differential/717/display/redirect

(arcanist seems to have lost the ability to apply dependencies before applying dependants.)

I applied D1582 and then this patch (@s0600204 said it's dependent on D1582) and I got a complete build on Slackware64-current with gcc 8.2

Also builds on Debian 9 using gcc 6.3

Thanks for confirming that this works. Good to know!

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/718/display/redirect

I tested this patch using Travis..

https://travis-ci.org/andy5995/0ad/builds/417846934

So I can confirm it builds on Ubuntu trusty using gcc 4.8, 5, 6, 7, 8 and clang 5 and 6.

@Itms @s0600204 The ticket where this build failure is reported is on the a23 milestone and I'm not sure if this irrelevant enough to be pushed. There was another bugreport on Nov 20th on the lobby:

Maanyavar: 0ad doesnt work on slackware 14.2

Secondly this is also a gloox premake patch, so this might or might not influence D1654 and vice versa:

gloox has its own config program: gloox-config. When run with the appropriate argument (--cflags) this was returning /usr/include, a directory that is included by default by gcc anyway and, as mentioned in D1582, a directory that if included too early causes problems.

In D1611#66598, @elexis wrote:

Secondly this is also a gloox premake patch, so this might or might not influence D1654 and vice versa:

gloox has its own config program: gloox-config. When run with the appropriate argument (--cflags) this was returning /usr/include, a directory that is included by default by gcc anyway and, as mentioned in D1582, a directory that if included too early causes problems.

They'll no doubt be a merge conflict, but nothing further - the OSX build method continues to use the GLOOX_CONFIG override before and after both this and that patch, so changing other *nix-type systems to use pkg-config in this patch should have no effect on the logic of that patch.

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/822/

In D1611#67371, @Itms wrote:

• Android is always left out. This does not come from the patch, but it makes it very apparent. Do you think moving that logic somewhere else would make sense? (most libraries must be ignored on Android, so it would be better to mark the ones that are needed, rather than the ones that must be ignored). Maybe leaving it like this would still be better, I don't know.

Hmm. To be honest, I may have been a little over-zealous with adding if not _OPTIONS["android"]. I've gone through and removed all that I added where there wasn't one before.

I don't think moving the logic elsewhere makes much sense - this file is used for working out how to include dependencies for all other OSes, so having it "all OSes... except Android which is handled over there" seems wrong somehow (even if "there" is elsewhere within the same file). Lets be honest, the build system is confusing enough without adding further special-casing ? (particularly for something that isn't really a priority, nor has seen much attention (from a development perspective) for four years).

Successful build - Chance fights ever on the side of the prudent.

Linter detected issues:
Executing section Source...

source/lib/sysdep/os/unix/x/x.cpp
|   1| /*·Copyright·(C)·2013·Wildfire·Games.
|    | [NORMAL] LicenseYearBear:
|    | License should have "2019" year instead of "2013"
Executing section JS...
Executing section cli...

Link to build: https://jenkins.wildfiregames.com/job/differential/945/

@Itms do you have any other comments on this ?

@wraitii Would you have time to test this on a mac?

Probably will at some point this WE. Be sure to remind me if I forget

We have a user with both libpng12 and libpng16 installed and I wonder why it doesn't use pkgconfig?

In D1611#157299, @Stan wrote:

We have a user with both libpng12 and libpng16 installed and I wonder why it doesn't use pkgconfig?

On extern_libs5.lua, line 388, @Stan wrote:

Any reason why it wasn't done for libpng?

This revision replaces hard-coded locations (e.g. the X11 paths) and the various dependency-specific programs (e.g. xml2-config) in favour of pkg-config (where possible). libpng wasn't using hard-coded paths nor dependency-specific programs, so it wasn't touched.

Beyond that, libpng12 doesn't support being found by pkgconfig - that was added in libpng14. Thus, any user for whom libpng12 is the most current version on their system would be unable to build. This includes Ubuntu LTS 14.04 - which at the time that this revision was created wouldn't reach its EOL date for another eight months.

Roughly two years and six months later, any distros that haven't upgraded are (or should be) past their expected EOL date, so we could now use pkgconfig for libpng. (see D3610)