GDevelop.js 如何用 Emscripten 构建 C 核心为 WebAssembly 并选择调试变体【免费下载链接】GDevelop Open-source, cross-platform 2D/3D/multiplayer game engine designed for everyone.项目地址: https://gitcode.com/GitHub_Trending/gd/GDevelopGDevelop.js 是 GDevelop 核心 C 类GDCore、GDJS到 WebAssembly JavaScript 的绑定层让编辑器核心能在浏览器或 Node.js 中运行。它的构建完全依赖 Emscripten 工具链当你修改了 C 扩展或核心类而不是纯 JavaScript 的编辑器代码时需要重新编译 GDevelop.js产出libGD.js和libGD.wasm再让 newIDE 编辑器使用这份本地构建。Binaries/README.md 说明该目录就是存放 GDCore 和 GDJS C 代码的 native/WebAssembly 二进制产物的位置具体编译步骤以 GDevelop.js/README.md 为准。先判断是否真的需要重新构建GDevelop.js/README.md开头明确说明如果你只是开发 GDevelop 编辑器或 JavaScript 扩展通常不需要重建 GDevelop.js只有修改了 C 扩展或 C 类时才需要读构建章节。newIDE 编辑器在开发模式下默认会自动下载现成的libGD.js本地构建的价值在于让编辑器以及npm test使用你自己编译出来的核心。准备安装 Emscripten 工具链构建前需要安装以下工具来自GDevelop.js/README.mdCMake 3.17README 注明 Linux/macOS 上 3.5 也可以工作macOS 推荐用 Homebrew 安装尤其 Apple M1 架构Node.js推荐用 nvm 管理版本Python推荐用 pyenv 管理版本然后安装指定版本的 Emscripten——文档要求版本3.1.21git clone https://github.com/emscripten-core/emsdk/ cd emsdk git pull ./emsdk install 3.1.21 ./emsdk activate 3.1.21 # On Windows, also install an additional Python package: pip install setuptools注意环境加载规则每次打开新的终端窗口构建 GDevelop.js 之前都要先加载 emsdk 环境否则后续 CMake 和update-bindings.js都找不到 EmscriptenLinux/macOSWindows (PowerShell)Windows (cmd.exe)source ./emsdk_env.sh./emsdk_env.ps1./emsdk_env.batGDevelop.js/update-bindings.js会检查EMSDK环境变量未设置时直接报错并提示运行emsdk_env脚本找不到$EMSDK/upstream/emscripten/tools/webidl_binder.py时也会报 Please check your Emscripten installation。执行构建在加载了 emsdk 环境的终端里从GDevelop.js目录发起构建cd GDevelop.js npm install # Only the first time. npm run build # After any C changes.npm run build对应的 npm script 是grunt build见 package.json。Gruntfile.js 展示了它实际的内部步骤与 README About the internal steps of compilation 一节一致mkdir:embuild创建Binaries/embuild构建目录shell:cmake在Binaries/embuild内用emcmake cmake ../..调用 CMake并传入-DGDEVELOPJS_BUILD_VARIANTvariant见下文选择调试变体。CMake 缓存存在时按CMakeCache.txt与CMakeLists.txt的时间戳决定是否重跑shell:updateGDBindings当Bindings/Bindings.idl比胶水代码新时运行node update-bindings.js调用 Emscripten 的 WebIDL Binder 从 Bindings.idl 重新生成glue.cpp和glue.js并打上补丁Bindings.idl本身描述了 GDevelop.js 暴露的全部 C 类shell:makeLinux/macOS 用emmake make -j 8编译Windows 默认用 NinjaGDevelop.js/ninja/ninja.exe也可以走 MinGW 路线见下文限制收尾任务copyToNewIDE把产物拷进编辑器目录generateFlowTypes/generateTSTypes从Bindings.idl重新生成类型声明。链接参数集中在 GDevelop.js/CMakeLists.txt 的target_link_libraries段几个关键项-s MODULARIZE1、-s EXPORT_NAMEinitializeGDevelopJs浏览器中的全局入口函数名、-s TOTAL_MEMORY48MB、-s ALLOW_MEMORY_GROWTH1。README 也提示如果想在堆栈或性能分析中看到函数名可以去改这里的编译/链接标志。根目录 CMakeLists.txt 中GDevelop.js子目录只在EMSCRIPTEN为真时才加入构建而GDevelop.js/CMakeLists.txt自身会做保护性检查——没有 Emscripten 环境直接触发FATAL_ERROR Youre trying to compile libGD.js without emscripten.。这解释了为什么构建必须在加载了 emsdk 的终端里跑。选择调试变体变体通过命令行传给 npm script由 Gruntfile 解析为GDEVELOPJS_BUILD_VARIANT。合法取值只有五个release、dev、debug、debug-assertions、debug-sanitizers不指定时默认release传了非法值会打印Invalid build variant: ...并直接退出。npm run build # 默认 release生产构建 npm run build -- --variantdev # 开发构建链接阶段不做 LTO链接更快 npm run build -- --variantdebug # 带调试信息stacktraces 有用 npm run build -- --variantdebug-assertions # 断言 SAFE_HEAP1找内存错误 npm run build -- --variantdebug-sanitizers # 内存 sanitizer非常慢各变体在 GDevelop.js/CMakeLists.txt 中对应的编译/链接差异变体编译期链接期用途README 原话要点release-O3 -flto-O3 -flto生产全优化 链接期优化dev-O3-O0开发全优化但跳过链接期优化README 称链接可快几秒debug-O3 -g --profiling-O0保留调试信息适合看 stack tracedebug-assertions-g --profiling-s ASSERTIONS2 -s SAFE_HEAP1运行时内存分配检查定位内存 bugdebug-sanitizers-g --profiling -fsanitizeaddress -fsanitizereturn -fsanitizenull-O1 -fsanitizeaddress -fsanitizenull -fsanitizereturn -s INITIAL_MEMORY512MB自动检测内存泄漏、use-after-free、溢出等README 标注 Will be very slow两个需要知道的细节debug-sanitizers用-s INITIAL_MEMORY512MB覆盖了前面设置的TOTAL_MEMORY48MBCMake 注释说明原因是 ASan 需要 256MB 隔离区加 shadow memory且反复增长内存有开销根目录 CMake 里还有一个USE_SANITIZERS选项cmake -DUSE_SANITIZERSaddress,undefined但它的生效条件是NOT EMSCRIPTEN即只用于 native 构建Emscripten 构建走的是上表的debug-sanitizers变体两者不要混用。验证构建产物构建成功的直接判据来自 copy-to-newIDE.js构建流程会检查Binaries/embuild/GDevelop.js/libGD.js和libGD.wasm是否存在——libGD.js不存在时报You must compile GDevelop.js firstlibGD.wasm不存在时报错退出。两者都会被复制到newIDE/app/public和newIDE/app/node_modules/libGD.js-for-tests-only成功时终端会打印Copied ... to public and node_modules folders of newIDE/app。功能层面的验证是跑测试GDevelop.js/package.json中test即jestcd GDevelop.js npm testREADME 的 Debugging 一节建议用debug-assertions或debug-sanitizers变体构建后跑一遍npm test检查 sanitizer/断言是否发现了明显的内存 bug。最后用编辑器实际消费这份构建GDevelop.js/README.md给出的步骤cd .. cd newIDE/app npm install npm startnewIDE/README.md 说明npm start会在浏览器中打开应用编辑器默认自动下载libGD.js自己构建的意义正是在你修改过 native 代码如 C 扩展时让编辑器加载你的本地版本。平台差异与限制Windows 构建器默认使用 NinjaGruntfile 会检查C:\Program Files\CMake等路径找 CMake找不到则要求 CMake 在 PATH 里npm run build-with-MinGW即grunt build --use-MinGW改用 MinGW 的 make但要求C:\MinGW\bin\mingw32-make.exe存在否则直接报错退出性能取舍dev变体只为加快链接README 原文称a few seconds faster, useful for development不改变产物优化程度debug-sanitizers构建和运行都会明显变慢适合定位问题而非日常开发构建类型CMAKE_BUILD_TYPE为空时根目录和GDevelop.js的 CMake 都默认按Release处理GDevelop.js侧还会据此定义RELEASE/DEBUG/DEV宏Windows 上的 Python 依赖README 要求额外pip install setuptools否则 emsdk 相关脚本可能无法运行。如果你要扩展的是 JavaScript 扩展而非 C 代码则不需要走这条构建链GDevelop.js/README.md指出的分界线就是是否改了 C。【免费下载链接】GDevelop Open-source, cross-platform 2D/3D/multiplayer game engine designed for everyone.项目地址: https://gitcode.com/GitHub_Trending/gd/GDevelop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
GDevelop.js 如何用 Emscripten 构建 C++ 核心为 WebAssembly 并选择调试变体
GDevelop.js 如何用 Emscripten 构建 C 核心为 WebAssembly 并选择调试变体【免费下载链接】GDevelop Open-source, cross-platform 2D/3D/multiplayer game engine designed for everyone.项目地址: https://gitcode.com/GitHub_Trending/gd/GDevelopGDevelop.js 是 GDevelop 核心 C 类GDCore、GDJS到 WebAssembly JavaScript 的绑定层让编辑器核心能在浏览器或 Node.js 中运行。它的构建完全依赖 Emscripten 工具链当你修改了 C 扩展或核心类而不是纯 JavaScript 的编辑器代码时需要重新编译 GDevelop.js产出libGD.js和libGD.wasm再让 newIDE 编辑器使用这份本地构建。Binaries/README.md 说明该目录就是存放 GDCore 和 GDJS C 代码的 native/WebAssembly 二进制产物的位置具体编译步骤以 GDevelop.js/README.md 为准。先判断是否真的需要重新构建GDevelop.js/README.md开头明确说明如果你只是开发 GDevelop 编辑器或 JavaScript 扩展通常不需要重建 GDevelop.js只有修改了 C 扩展或 C 类时才需要读构建章节。newIDE 编辑器在开发模式下默认会自动下载现成的libGD.js本地构建的价值在于让编辑器以及npm test使用你自己编译出来的核心。准备安装 Emscripten 工具链构建前需要安装以下工具来自GDevelop.js/README.mdCMake 3.17README 注明 Linux/macOS 上 3.5 也可以工作macOS 推荐用 Homebrew 安装尤其 Apple M1 架构Node.js推荐用 nvm 管理版本Python推荐用 pyenv 管理版本然后安装指定版本的 Emscripten——文档要求版本3.1.21git clone https://github.com/emscripten-core/emsdk/ cd emsdk git pull ./emsdk install 3.1.21 ./emsdk activate 3.1.21 # On Windows, also install an additional Python package: pip install setuptools注意环境加载规则每次打开新的终端窗口构建 GDevelop.js 之前都要先加载 emsdk 环境否则后续 CMake 和update-bindings.js都找不到 EmscriptenLinux/macOSWindows (PowerShell)Windows (cmd.exe)source ./emsdk_env.sh./emsdk_env.ps1./emsdk_env.batGDevelop.js/update-bindings.js会检查EMSDK环境变量未设置时直接报错并提示运行emsdk_env脚本找不到$EMSDK/upstream/emscripten/tools/webidl_binder.py时也会报 Please check your Emscripten installation。执行构建在加载了 emsdk 环境的终端里从GDevelop.js目录发起构建cd GDevelop.js npm install # Only the first time. npm run build # After any C changes.npm run build对应的 npm script 是grunt build见 package.json。Gruntfile.js 展示了它实际的内部步骤与 README About the internal steps of compilation 一节一致mkdir:embuild创建Binaries/embuild构建目录shell:cmake在Binaries/embuild内用emcmake cmake ../..调用 CMake并传入-DGDEVELOPJS_BUILD_VARIANTvariant见下文选择调试变体。CMake 缓存存在时按CMakeCache.txt与CMakeLists.txt的时间戳决定是否重跑shell:updateGDBindings当Bindings/Bindings.idl比胶水代码新时运行node update-bindings.js调用 Emscripten 的 WebIDL Binder 从 Bindings.idl 重新生成glue.cpp和glue.js并打上补丁Bindings.idl本身描述了 GDevelop.js 暴露的全部 C 类shell:makeLinux/macOS 用emmake make -j 8编译Windows 默认用 NinjaGDevelop.js/ninja/ninja.exe也可以走 MinGW 路线见下文限制收尾任务copyToNewIDE把产物拷进编辑器目录generateFlowTypes/generateTSTypes从Bindings.idl重新生成类型声明。链接参数集中在 GDevelop.js/CMakeLists.txt 的target_link_libraries段几个关键项-s MODULARIZE1、-s EXPORT_NAMEinitializeGDevelopJs浏览器中的全局入口函数名、-s TOTAL_MEMORY48MB、-s ALLOW_MEMORY_GROWTH1。README 也提示如果想在堆栈或性能分析中看到函数名可以去改这里的编译/链接标志。根目录 CMakeLists.txt 中GDevelop.js子目录只在EMSCRIPTEN为真时才加入构建而GDevelop.js/CMakeLists.txt自身会做保护性检查——没有 Emscripten 环境直接触发FATAL_ERROR Youre trying to compile libGD.js without emscripten.。这解释了为什么构建必须在加载了 emsdk 的终端里跑。选择调试变体变体通过命令行传给 npm script由 Gruntfile 解析为GDEVELOPJS_BUILD_VARIANT。合法取值只有五个release、dev、debug、debug-assertions、debug-sanitizers不指定时默认release传了非法值会打印Invalid build variant: ...并直接退出。npm run build # 默认 release生产构建 npm run build -- --variantdev # 开发构建链接阶段不做 LTO链接更快 npm run build -- --variantdebug # 带调试信息stacktraces 有用 npm run build -- --variantdebug-assertions # 断言 SAFE_HEAP1找内存错误 npm run build -- --variantdebug-sanitizers # 内存 sanitizer非常慢各变体在 GDevelop.js/CMakeLists.txt 中对应的编译/链接差异变体编译期链接期用途README 原话要点release-O3 -flto-O3 -flto生产全优化 链接期优化dev-O3-O0开发全优化但跳过链接期优化README 称链接可快几秒debug-O3 -g --profiling-O0保留调试信息适合看 stack tracedebug-assertions-g --profiling-s ASSERTIONS2 -s SAFE_HEAP1运行时内存分配检查定位内存 bugdebug-sanitizers-g --profiling -fsanitizeaddress -fsanitizereturn -fsanitizenull-O1 -fsanitizeaddress -fsanitizenull -fsanitizereturn -s INITIAL_MEMORY512MB自动检测内存泄漏、use-after-free、溢出等README 标注 Will be very slow两个需要知道的细节debug-sanitizers用-s INITIAL_MEMORY512MB覆盖了前面设置的TOTAL_MEMORY48MBCMake 注释说明原因是 ASan 需要 256MB 隔离区加 shadow memory且反复增长内存有开销根目录 CMake 里还有一个USE_SANITIZERS选项cmake -DUSE_SANITIZERSaddress,undefined但它的生效条件是NOT EMSCRIPTEN即只用于 native 构建Emscripten 构建走的是上表的debug-sanitizers变体两者不要混用。验证构建产物构建成功的直接判据来自 copy-to-newIDE.js构建流程会检查Binaries/embuild/GDevelop.js/libGD.js和libGD.wasm是否存在——libGD.js不存在时报You must compile GDevelop.js firstlibGD.wasm不存在时报错退出。两者都会被复制到newIDE/app/public和newIDE/app/node_modules/libGD.js-for-tests-only成功时终端会打印Copied ... to public and node_modules folders of newIDE/app。功能层面的验证是跑测试GDevelop.js/package.json中test即jestcd GDevelop.js npm testREADME 的 Debugging 一节建议用debug-assertions或debug-sanitizers变体构建后跑一遍npm test检查 sanitizer/断言是否发现了明显的内存 bug。最后用编辑器实际消费这份构建GDevelop.js/README.md给出的步骤cd .. cd newIDE/app npm install npm startnewIDE/README.md 说明npm start会在浏览器中打开应用编辑器默认自动下载libGD.js自己构建的意义正是在你修改过 native 代码如 C 扩展时让编辑器加载你的本地版本。平台差异与限制Windows 构建器默认使用 NinjaGruntfile 会检查C:\Program Files\CMake等路径找 CMake找不到则要求 CMake 在 PATH 里npm run build-with-MinGW即grunt build --use-MinGW改用 MinGW 的 make但要求C:\MinGW\bin\mingw32-make.exe存在否则直接报错退出性能取舍dev变体只为加快链接README 原文称a few seconds faster, useful for development不改变产物优化程度debug-sanitizers构建和运行都会明显变慢适合定位问题而非日常开发构建类型CMAKE_BUILD_TYPE为空时根目录和GDevelop.js的 CMake 都默认按Release处理GDevelop.js侧还会据此定义RELEASE/DEBUG/DEV宏Windows 上的 Python 依赖README 要求额外pip install setuptools否则 emsdk 相关脚本可能无法运行。如果你要扩展的是 JavaScript 扩展而非 C 代码则不需要走这条构建链GDevelop.js/README.md指出的分界线就是是否改了 C。【免费下载链接】GDevelop Open-source, cross-platform 2D/3D/multiplayer game engine designed for everyone.项目地址: https://gitcode.com/GitHub_Trending/gd/GDevelop创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
