Add support for WebAssembly builds of some 3p-packages#284
Add support for WebAssembly builds of some 3p-packages#284nick-l-o3de merged 14 commits intoo3de:mainfrom
Conversation
|
|
||
| cmake_generate_cmd = [self.cmake_command, | ||
| # emcmake self configure the proper environment when targeting WebAssembly | ||
| cmake_command = self.cmake_command |
There was a problem hiding this comment.
I am unsure about this approach, we might want to setup the same environment as emcmake is doing in the configure json file. Yet this is the easiest and lowest maintenance path so I let the build system pro decide on what is best
| @@ -1 +1,2 @@ | |||
| package-system/Crashpad/add_o3de_handler_extensions.patch eol=lf | |||
There was a problem hiding this comment.
.gitattributes files can be in any folder, why not put this in a .gitattributes file in the same folder as the file it affects?
| "custom_additional_compile_definitions":[ | ||
| "GTEST_HAS_TR1_TUPLE=0", | ||
| "GTEST_OS_SUPPORTS_DEATH_TEST=0" | ||
| ] |
There was a problem hiding this comment.
I'm under the impression that we now build googletest as an inline fetchcontent build, this package is unused. see Code\Framework\AzTest\3rdParty\Findgoogletest.cmake
package_build_list_host_windows.json
Outdated
| "googlebenchmark-1.7.0-rev1-windows": "Scripts/extras/pull_and_build_from_git.py ../../package-system/googlebenchmark --platform-name Windows --package-root ../../package-system --clean", | ||
| "googletest-1.8.1-rev4-android": "Scripts/extras/pull_and_build_from_git.py ../../package-system/googletest --platform-name Android --package-root ../../package-system --clean", | ||
| "googletest-1.8.1-rev4-windows": "Scripts/extras/pull_and_build_from_git.py ../../package-system/googletest --platform-name Windows --package-root ../../package-system --clean", | ||
| "googletest-1.8.1-rev4-emscripten": "Scripts/extras/pull_and_build_from_git.py ../../package-system/googletest --platform-name Emscripten --package-root ../../package-system --clean", |
There was a problem hiding this comment.
As above.. you can do this, but the engine doesn't use it.
|
Noted just updated the files following your feedbacks :) |
|
This looks good, but how do we want to proceed with this, should we keep this alive while the emscripten changes happen on o3de, until its all in, or do you expect no further revisions of this package need be made? |
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
41ca648 to
91a0674
Compare
Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
## What does this PR do? Related to : - #19083 - o3de/3p-package-source#284 Allow O3DE to be configured by [Emscripten](https://emscripten.org/) compiler to target webassembly. Configuration will just fail on the missing 3p dependencies which will be progressively added by the PR above and its follow-ups. Right now, removing occurences of these 3p-packages in the few cmake files using them will allow the configuration to succeed, and allow anyone to try building and start fixing compilation issues. **Convention** Emscripten is as much a platform as it is a compiler, they decided to use an [unix-like API](https://emscripten.org/docs/api_reference/Filesystem-API.html) for the file system etc but you could implement a C++ to WebAssembly compiler exposing windows-like API. This is why the Platform Abstraction Layer uses `emscripten` as a name instead of `wasm` ## How was this PR tested? Tried on Windows development branch Setup : - Follow emscripten [install instruction](https://emscripten.org/docs/getting_started/downloads.html) - Install ninja build system - Build the 3p package from emscripten using the branch above - In the emscripten o3de branch. Create a new folder "wasm", go inside, and run `emcmake cmake .. -DLY_3RDPARTY_PATH=YOUR_PATH` -> As stated above, will currently fail here - Then build with `cmake --build .` Signed-off-by: guillaume-haerinck <guillaume.haerinck@outlook.com>
What does this PR do?
Allow to build several 3p package to the WebAssembly target thanks to emscripten compiler
Related to :
What remains :
How was this PR tested?
Local build on windows.
Setup required for now:
Steps:
python .\build_package.py --search_path ..\..\3p-package-source Lua-5.4.4-rev1-emscriptenemcmake cmake .. -DLY_3RDPARTY_PATH=YOUR_PATHthen build the test targets)