Build systems drop discussion

[a1batross]

I'm suggesting removal of Android.mk or moving it somewhere, pointing out that it's not supported anymore, nor by us, nor by NDK developers.

At this time, we have alternatives, that are actively used in hlsdk-xash3d development:

1. CMake.

• Pros:

  • Supported by Android NDK devs officially

• Cons:

  • Doesn't support older NDKs with GCC and hardfp ABI.

2. Waf with waifu's xcompile.py.

• Pros:

  • We already using it for building new engine for Android.
  • xcompile.py supports older NDKs, GCC, hardfp ABI and even using host Clang for better optimizations.

• Cons:

  • ?

However, I don't want to rush anyone and I can't call myself a maintainer of hlsdk-xash3d, so I can't decide for everyone here.

Casting everyone who develop their mods on hlsdk-xash3d. :) @mittorn @nekonomicon @FreeSlave @AimlessWanderer @DrBeef @nillerusr

Upd: formatting

[nekonomicon]

Android.mk used with microndk on non-Android platforms. CMake is more flexible and supported by MSVC. Waf required knowledge of python and not obvious how to use it. Compile.sh - useful for MSVC. Makefile for GNU Make - must be removed I think.

[a1batross]

Yeah, I've forgot about Microndk. That's may be the case.

compile.sh for MSVC6 can be replaced theoretically by Waf, but for Windows it's an external dependency. I don't know who will be working with MSVC6 in 2020, as even Unkle Mike has stopped using it.

Makefile for GNU Make - must be removed I think.

Haha, I've forgot about this one.

[FreeSlave]

Personally I use only cmake and compile.bat (for easy windows builds via shtudio and wine) Can you write docs on the waf usage?

[mittorn]

I think, we need to embed mod build to engine build system. Waf is more complex than Android.mk, so keeping different versions of waf and merging it in every mod will be harder, but just importing configuration from engine and keeping only file lists in mods would be better (options/configure/build section are almost standard)

[a1batross]

@mittorn yeah, main wscript of hlsdk and engine are mostly copypasted.

Still, I don't get the idea. You're suggesting to build HLSDK inside of engine?

[a1batross]

@FreeSlave I'm gonna do this at some point, but for now it's enough to:

1. Learn python. Almost everyone knows python a bit, it's not a big problem.
2. Read https://waf.io/book, especially C/C++ section.
3. Read the ./waf --help to know project specific options.

[mittorn]

Yes, need ability to put sdk root wscript to engine project to build automaticly. Ports authors need to build dozen of different sdks in this ports. Are you have any idea for it? Also, mod developers need standalone wscript (with waf and python binaries included when need). Maybe split it from sdk and download when needed?

[DrBeef]

Firstly, thank-you for including me on this discussion!, I'm pretty honoured to be honest. My use of Xash3D and the Xash3D HLSDK in my project was initially a bit like a caveman bashing rocks together hoping to make fire, but as time has progressed I have got a fairly good understanding of how things hang together, but I still feel like a bit of a hacker, so please excuse me if the following is a bit jumbled.

I do actually use the Android.mk files at the moment when building the hlsdk, and I think similar to how @mittorn was saying, I build the hlsdk as part of the complete build/package of Lambda1VR all from within Android Developer Studio. If the HLSDK portion was to be changed to use cmake then I expect it would be quite straightforward for me to adopt that instead if it is supported natively by ADS (which it looks like it is). If another approach (waf) was used then I would probably have to maintain my own local Android.mk or CMake file, just to keep my project building within ADS, but to be honest that's not a major headache.

At the moment I am only building my vr-customised version of the main hlsdk branch. I am hoping in the future to get some other mods working (they will also require changes to be vr-compatible), but for now I only worry about the one branch.

[a1batross]

@DrBeef I think, we're not gonna remove Android.mks at this time, probably until G[censored] will remove it from NDK completely, as they did with GCC, older API targets and so on...

HLSDK isn't hard to support different build systems, unlike the engine.

The problem with Waf for Android is that it is unsupported by G[censored], so you can't use it with Android Studio directly. We're not using this IDE in development and we're do not support nor CMake/Androidmk, nor Gradle to build the engine. I understand, it may be hurtful for "normal" Android developers but I personally do not want switch to them.

btw I wonder how Android Studio still supports Androidmk. When I tried it last time, it wanted to force me use CMake. :) I even seen that CryEngine developers even made a gradle/cmake project generators so they can be loaded into Android Studio.

@mittorn I don't understand how it will help mod makers(except DrBeef who is actually modding the engine itself). Yes, you can build HLSDK inside of engine source tree, just by including HLSDK subdirectory into SUBDIRS variable.

One of examples where HLSDK is built as part of something else is xash3d-android-project(waf branch).

[mittorn]

Our waf in under active development now and we have dozens of differend mod source trees, so updating it may be hard. Android.mk have very simple format and most of mods just use it for file list. About android studio: does it support Android.mk at all? I think it is completely unuseful for mod development as it is for java mostly

[mittorn]

May we import gradle/cmake generators from crywaf?

[a1batross]

No, they are proprietary.