Building the NativeClient loader as part of the engine build?

[illwieckz]

Right now we ship the loader (nacl_loader, nacl_helper_bootstrap) with the external deps.

With the ongoing efforts of making it rebuildable easily, especially the CMake effort, it will become possible to rebuild the loader as part of the engine build itself:

• Write a CMakeLists.txt to build the NaCl loader native_client#2

The proposal is that it would be rebuilt as a CMake sub-project, to not pollute engine CFLAGS and don't get CFLAGS pollution from engine.

We may as a start only build the native loader and ship the irt nexe with the external deps, since we also have a plan to repackage saigo, if we manage to build the irt nexe with saigo we may include the irt nexe build as part of the engine build too, and that could be done for every platform.

There are special cases:

• macos-arm64 can probably build the macos-amd64 loader with some compiler flag, so the rebuild will probably be enabled.
• linux-arm64 would require an armhf compiler so we may make the rebuild of the loader optional and ship it in external deps, unless we find a compiler flag that can turn an arm64 compiler into an armhf one (not sure if -m32 would be enough). We would also need to ship the armhf libc in the external deps for the loader, unless we find a way to get a working statically built loader.
• freebsd-amd64 would use a precompiled loader from the deps, as getting a linux cross-compiler on freebsd is too much complex.
• I do remember having read that either windows-amd64 or windows-i686 may rely on MinGW for building one file even when MSVC is the compiler, so we have to check that and if true, the loader for such platform would have to be shipped prebuilt in external deps.

[illwieckz]

I do remember having read that either windows-amd64 or windows-i686 may rely on MinGW for building one file even when MSVC is the compiler

I found it, it's mentionned in the comment in my CMake file (itself copied from SCons):

		# We use the GNU assembler (gas) on Windows so that we can use the
		# same .S assembly files on all platforms.  Microsoft's assembler uses
		# a completely different syntax for x86 code.
#FIXME: Use x86_64-w64-mingw32-as.exe or x86_64-w32-mingw32-as.exe on MSVC for .S files.

So that's an MSVC limitation only, so we may build the Windows NaCl loader as part of the engine build when building with MinGW, and ship it as prebuilt for MSVC.

[slipher]

Sounds like a bad idea to me. NaCl only builds on a finite set of platforms so we wouldn't gain any more portability. As hinted above it uses some build tools that we currently don't depend on, so there would be a greater chance of the build not competing successfully with some toolchains. NaCl is something that very few people will want to hack on, so there is little benefit in easily modifying it. I don't understand what the benefit is supposed to be.

[illwieckz]

The benefit would be to not enforce the download of a precompiled binary when the build is straightforward on the platform. On Linux with my CMake configuration it would just require to add the NaCl loader as a CMake subproject (just to not pollute the compiler flags) in Dæmon CMake. The loader is a very important part of the engine, and is fast to build.