CMake vs XMake

[narknon]

Vote for whether we keep the port to XMake or swap back to CMake.

[localcc]

Why we should not use a vote and instead compare the products based on the feature set.

XMake and CMake have their own pros and cons. The issue of choosing a build system should not be chosen in a vote, instead we should list pros and cons of each and compare them. This allows us to cleanly look at tradeoffs we are making, while elminating personal biases.

CMake

I will start with CMake as that's what most are familiar with.

CMake has been around for a really long time, which gives it some advantages, as well as disadvantages.

CMake pros:

• A lot of existing docs and help articles for common problems
• More functionality of it is tested and works without bugs
• Docs are informative and nicely indexable by google

Cmake cons:

• If there are 3 ways to do something, cmake will do all 3 and invent yet another one. A prominent example of this is build configurations and how much work needs to be done to support every generator that cmake has.
• Doesn't work on every machine. This issue was most prominent once we added rust to our codebase, which made some people completely unable to build code.
• Build generator inconsistency. This ties in to previous points, but there is more to that. Custom commands work weirdly in different generators. This was a problem when we were generating the proxy files as part of the build.

Xmake

Now let's switch gears to xmake. xmake is a fairly new build system, which is designed to interoperate with existing build systems to ease transition, as well as be easier than existing ones.

xmake pros:

• If it works for you, it works on every other machine. This was proven after we migrated to xmake and everyone that tried to build ue4ss succeeded doing so, even people that were having issues with cmake.
• It's consistent, if your code works for one of the generators, it will work for every generator (at least so happened during my testing, and no issues were reported to me with other generators not working)
• Interoperability. We don't need to rewrite every dependency's code to use it, it works with cmake and multiple other build systems.
• Debuggability. Xmake is (in my opinion) much more debuggable. Setting breakpoints and debugging running build scripts is possible with a plugin for vscode. And what is even better in my opinion, is the ability to edit xmake source lua files with debug prints and debug what is wrong that way.

xmake cons:

• Not so good documentation. The docs are poorly indexed by google and searching through them can be a nightmare.
• Is fairly young, so some bugs might've been uncaught, and the userbase is much less.
• Less community posts, so solving common issues might be a bit tougher.

[narknon]

Please refer to this post for how polls work. #142

[UE4SS]

This post is useful for deciding what to vote for.

[Yangff]

I didn't vote because my current grudge against xmake might make me ignore some of the problems that cmake also has.
First the issue of custom commands, I'm not quite sure what the issue being discussed here is. But I generally generate the project containing the custom commands target as a separate target, and then specify via dependencies that the project using the generated file has a dependency on it. That is (in the case of proxygen) proxy_gen -> proxy_header (contains custom command output) -> proxy. So far I haven't had a problem with it not working.

The biggest problem with xmake I think is reproducibility due to its cache. If you look at the original PR for the xmake migration, you'll see that a lot of the time xmake may work, but it needs to be cleaned or reclone to reflect the latest updates, and in other cases it is not working but appear to so because people are not cleaning the cache, which is almost unacceptable in my opinion.
The building system itself shouldn't be the source of the problem, I mean, it may or may not work, that is okay.
I can try to fix or workaround the weird problems I'm having, it's just going to take a little more time.
But the result at that point should be clear and certain. I shouldn't be drawing time on researching whether my make script is wrong or if xmake is messing with it.
The same thing happens after I've changed my code, and it's a serious blow to efficiency and mood if my code edits aren't responded to truthfully by the build system.

xmake uses strange concurrency mechanisms on compilation while shedding contextual information. This is a serious blow to debugging. Because we're not debugging xmake, we're debugging xmake scripts. But this mechanism of xmake makes errors separate from the scene and context. We're not developing micro services that are deployed on 1000 machines at the same time, and xmake's abstraction complicates even very simple problems.

[Yangff]

An example for the useless error message. It says conflict deps on util-macros in glfw.

error: @programdir/core/main.lua:329: @programdir/modules/private/action/require/impl/package.lua:1115: package(util-macros/latest:{"runtimes=","toolchains=table: 0x558506900580"}): conflict dependences with package(util-macros/latest:{"runtimes=","toolchains=table: 0x5585065bf500"}) in glfw!
stack traceback:
    [C]: in function 'error'
    [@programdir/core/base/os.lua:957]: in function 'raiselevel'
    [@programdir/core/sandbox/modules/utils.lua:143]: in function 'assert'
    [@programdir/modules/private/action/require/impl/package.lua:1115]: in function '_check_package_depconflicts'
    [@programdir/modules/private/action/require/impl/package.lua:1345]: in function 'load_packages'
    [...modules/private/action/require/impl/install_packages.lua:667]:
    [@programdir/modules/private/action/require/install.lua:85]:
    [@programdir/actions/config/main.lua:387]:
    [C]: in function 'xpcall'
    [@programdir/core/base/utils.lua:275]:
    [@programdir/core/base/task.lua:491]: in function 'run'
    [@programdir/core/main.lua:327]: in function 'cotask'
    [@programdir/core/base/scheduler.lua:406]:

stack traceback:
        [C]: in function 'error'
        @programdir/core/base/os.lua:957: in function 'base/os.raiselevel'
        (...tail calls...)
        @programdir/core/main.lua:329: in upvalue 'cotask'
        @programdir/core/base/scheduler.lua:406: in function <@programdir/core/base/scheduler.lua:399>
error: @programdir/core/sandbox/modules/os.lua:378: execv(/home/yangff/.local/bin/xmake f --diagnosis --verbose -y -c --plat=linux --arch=x86_64 --mode=release --kind=static --runtimes= --cxflags=-fPIC --buildir=build_505b036b --dx12=false --freetype=false --sdl2=false --opengl3=true --vulkan=false --dx9=false --sdl2_renderer=false --glfw=true --dx10=false --dx11=true --glad=false --opengl2=false --win32=true --wgpu=false --wchar32=false) failed(255)
stack traceback:
    [C]: in function 'error'
    [@programdir/core/base/os.lua:957]:
    [@programdir/core/sandbox/modules/os.lua:378]:
    [@programdir/core/sandbox/modules/os.lua:291]: in function 'vrunv'
    [@programdir/modules/package/tools/xmake.lua:511]: in function 'install'
    [...xmake/repositories/xmake-repo/packages/i/imgui/xmake.lua:157]: in function 'script'
    [...dir/modules/private/action/require/impl/utils/filter.lua:114]: in function 'call'
    [.../modules/private/action/require/impl/actions/install.lua:369]:

  => install imgui v1.89 .. failed

So first, glfw conflict with whom on util-macros? no clue. why they conflict? I'm seeing exactly the same package signature package(util-macros/latest:{"runtimes=","toolchains=table: 0x558506900580"}): vs. package(util-macros/latest:{"runtimes=","toolchains=table: 0x5585065bf500"}) but xmake say conflict.

The stack trace is not bringing me where either deps are defined. Is it somewhere in out scripts, or any of the xmake's xrepo scripts. It just shows its internal stack trace which is totally useless.. I don't care about how you calcuate that confilct and raise at some point, I care about where the conflict comes from and why. None of them are given by the error message, searching on xmake's repo also gives no clue about it.

[UE4SS]

Is it not possible to see who voted for what ?
If not, this poll (and many other future ones) is useless because we can't tell if non-devs have voted or what they might have voted for, which means if it's a dev related poll the results won't actually be representative of what the devs want.
There are currently 13 votes, do we even have that many active devs ?

[localcc]

I will voice my opinion here again, voting for any architectural changes is a stupid idea. We should not be concerned with a majority vote, and instead we should clearly look at the tradeoffs each method provides, and decide from that. Also poll not even showing who voted really invalidates any clear judgement because people who have never heard of xmake would've just voted for cmake.

[UE4SS]

I agree with this.
However, a vote (where you know who voted for what, or at least one guaranteed to only be devs) is still a useful tool to tally what everyone wants to do after a discussion has been had.

[narknon]

Polls aren't votes, it's a poll. It's purely informative and allows for discussion.

[narknon]

I realize I said vote in the caption, but that wasn't the intended connotation.

[trumank]

For what it's worth, I've managed to get UE4SS to build on Linux using both msvc (under wine) and clang-cl, and now even have clangd working perfectly in VS Code. I have not managed to get it to build at all through xmake on Linux yet, though I have not invested quite as much time into it.

[Yangff]

Here are some additional ideas about building (which might not be closely related to xmake but are influenced by it):

Compared to directly using the clang/gnu toolchain, zig cc can provide better binary compatibility across different Linux distributions and Windows. For example, it can specify the symbol version of glibc. The advantage here is that we can freely use newer GitHub action images without worrying about library versions affecting user availability (akin to cross-compiling local libraries on Linux, using zig cc -target x86_64-linux-gnu.version).
Additionally, it does not require an SDK or sysroot for cross-compiling (though you might need to build libraries like libncurses yourself). This is more user-friendly for mod developers who primarily use Windows as they do not need to use strange SDKs (my idea was to use the official UE SDK, but its clang version is too low) and can cross-compile without a Linux environment if their development is only about integrating some higher-level libraries (like adding networking features, etc.).

xmake supports zig/zigcc, but it cannot work with cmake because cmake requires the compiler that xmake passes to be an executable file, which is not the case for zig cc as cc is a parameter of zig and cmake cannot find a file named zig cc. xmake-io/xmake#4848

I think this can be resolved by packaging a zig-cc, but I haven't figured out how to make xmake accept this name. Using set_toolset results in an error saying the script cannot be found.