Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Initial Support for xeus-cpp-lite #199

Merged
merged 6 commits into from
Dec 24, 2024
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions .github/workflows/deploy-github-page.yml
Original file line number Diff line number Diff line change
Expand Up @@ -59,13 +59,15 @@ jobs:
echo "PREFIX=$PREFIX" >> $GITHUB_ENV
export CMAKE_PREFIX_PATH=$PREFIX
export CMAKE_SYSTEM_PREFIX_PATH=$PREFIX
export SYSROOT_PATH=$HOME/emsdk/upstream/emscripten/cache/sysroot

emcmake cmake \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_PREFIX_PATH=$PREFIX \
-DCMAKE_INSTALL_PREFIX=$PREFIX \
-DXEUS_CPP_EMSCRIPTEN_WASM_BUILD=ON \
-DCMAKE_FIND_ROOT_PATH_MODE_PACKAGE=ON \
-DSYSROOT_PATH=$SYSROOT_PATH \
..
emmake make -j ${{ env.ncpus }} install

Expand All @@ -76,6 +78,8 @@ jobs:
micromamba activate xeus-lite-host
python -m pip install jupyterlite-xeus
jupyter lite build --XeusAddon.prefix=${{ env.PREFIX }} --output-dir dist
cp xcpp.data dist/extensions/@jupyterlite/xeus/static
cp $PREFIX/lib/libclangCppInterOp.so dist/extensions/@jupyterlite/xeus/static
mkdir -p dist/files
mv notebooks dist/files
mv README.md dist/files
Expand Down
4 changes: 4 additions & 0 deletions .github/workflows/main.yml
Original file line number Diff line number Diff line change
Expand Up @@ -257,13 +257,15 @@ jobs:
echo "PREFIX=$PREFIX" >> $GITHUB_ENV
export CMAKE_PREFIX_PATH=$PREFIX
export CMAKE_SYSTEM_PREFIX_PATH=$PREFIX
export SYSROOT_PATH=$HOME/emsdk/upstream/emscripten/cache/sysroot

emcmake cmake \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_PREFIX_PATH=$PREFIX \
-DCMAKE_INSTALL_PREFIX=$PREFIX \
-DXEUS_CPP_EMSCRIPTEN_WASM_BUILD=ON \
-DCMAKE_FIND_ROOT_PATH_MODE_PACKAGE=ON \
-DSYSROOT_PATH=$SYSROOT_PATH \
..
emmake make -j ${{ env.ncpus }} install

Expand All @@ -274,6 +276,8 @@ jobs:
micromamba activate xeus-lite-host
python -m pip install jupyterlite-xeus
jupyter lite build --XeusAddon.prefix=${{ env.PREFIX }}
cp xcpp.data _output/extensions/@jupyterlite/xeus/static
cp $PREFIX/lib/libclangCppInterOp.so _output/extensions/@jupyterlite/xeus/static

- name: Setup tmate session
if: ${{ failure() && runner.debug }}
Expand Down
37 changes: 33 additions & 4 deletions CMakeLists.txt
Original file line number Diff line number Diff line change
Expand Up @@ -84,7 +84,7 @@ if(EMSCRIPTEN)
set(XEUS_CPP_USE_SHARED_XEUS_CPP OFF)
set(XEUS_CPP_BUILD_TESTS OFF)
# ENV (https://github.com/emscripten-core/emscripten/commit/6d9681ad04f60b41ef6345ab06c29bbc9eeb84e0)
set(EMSCRIPTEN_FEATURES "${EMSCRIPTEN_FEATURES} -s \"EXTRA_EXPORTED_RUNTIME_METHODS=[ENV']\"")
set(EMSCRIPTEN_FEATURES "${EMSCRIPTEN_FEATURES} -s \"EXPORTED_RUNTIME_METHODS=[ENV']\"")
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EXTRA_EXPORTED_RUNTIME_METHODS had been deprecated in favour of EXPORTED_RUNTIME_METHODS since 2.0.18

endif()

# Dependencies
Expand Down Expand Up @@ -152,8 +152,22 @@ function(configure_kernel kernel)
endfunction()

message("Configure kernels: ...")
configure_kernel("/share/jupyter/kernels/xcpp17/")
configure_kernel("/share/jupyter/kernels/xcpp20/")
if(NOT EMSCRIPTEN)
anutosh491 marked this conversation as resolved.
Show resolved Hide resolved
configure_kernel("/share/jupyter/kernels/xcpp17/")
configure_kernel("/share/jupyter/kernels/xcpp20/")
else()
# TODO: Currently jupyterlite-xeus and xeus-lite do not provide
# methods to fetch information from the arguments present in the
# generated emscripten kernel.
# The following needs to be done here :
# 1) We need to configure the kernel properly
# Check issue https://github.com/compiler-research/xeus-cpp/issues/185.
# 2) Once the above is done we need to add support in jupyterlite-xeus & xeus-lite
# to be able to deal with arguments present in kernel.json
# 3) Finally we should fetch the C++ version from the kernel.json file and
# be able to pass it to our wasm interpreter rather than forcing a version.
configure_kernel("/share/jupyter/kernels/xcpp20/")
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO with respect to supporting more kernels raised here. We would be going ahead with xcpp20 for now but would like to support all.
Please let me know of any questions you'll have or this needs to be rephrased.

endif()

# Source files
# ============
Expand Down Expand Up @@ -401,8 +415,22 @@ if(EMSCRIPTEN)
xeus_cpp_set_kernel_options(xcpp)
xeus_wasm_compile_options(xcpp)
xeus_wasm_link_options(xcpp "web,worker")
target_link_options(xcpp PUBLIC
-sEXPORTED_RUNTIME_METHODS=FS,PATH,ERRNO_CODES
anutosh491 marked this conversation as resolved.
Show resolved Hide resolved
# add sysroot location here
--preload-file ${SYSROOT_PATH}/include@/include
)
# TODO: Emscripten supports preloading files just once before it generates
# the xcpp.data file (containing the binary representation of the file(s) we
# want to include in our application).
# Hence although we are adding supporting for Standard Headers, Libraries etc
# through emscripten's sysroot for now, we need to do the following:
# 1) Enable CppInterOp to provide us with a resource dir.
# 2) If the above cannot be done, we can use the resource dir provided
# by llvm on emscripten-forge but would involve adding a dependency.
# 3) Shift the resource dir and the sysroot to a common location.
# 4) Preload everything required together.
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO with respect to preloading raised here. Please let me know of any questions you'll have or this needs to be rephrased.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically speaking in the long run we would have a better method to load files (and libraries like clad, xsimd etc) dynamically using mambajs(https://github.com/emscripten-forge/mambajs) that is currently in the works.

endif()

# Tests
# =====

Expand Down Expand Up @@ -492,6 +520,7 @@ if(EMSCRIPTEN)
install(FILES
"$<TARGET_FILE_DIR:xcpp>/xcpp.js"
"$<TARGET_FILE_DIR:xcpp>/xcpp.wasm"
"$<TARGET_FILE_DIR:xcpp>/xcpp.data"
DESTINATION ${CMAKE_INSTALL_BINDIR})
endif ()

Expand Down
12 changes: 11 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -87,13 +87,15 @@ pushd build
export PREFIX=$MAMBA_ROOT_PREFIX/envs/xeus-cpp-wasm-host
export CMAKE_PREFIX_PATH=$PREFIX
export CMAKE_SYSTEM_PREFIX_PATH=$PREFIX
export SYSROOT_PATH=$HOME/emsdk/upstream/emscripten/cache/sysroot

emcmake cmake \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_PREFIX_PATH=$PREFIX \
-DCMAKE_INSTALL_PREFIX=$PREFIX \
-DXEUS_CPP_EMSCRIPTEN_WASM_BUILD=ON \
-DCMAKE_FIND_ROOT_PATH_MODE_PACKAGE=ON \
-DSYSROOT_PATH=$SYSROOT_PATH \
..
emmake make install
```
Expand All @@ -105,12 +107,20 @@ micromamba activate xeus-lite-host
python -m pip install jupyterlite-xeus
jupyter lite build --XeusAddon.prefix=$PREFIX
```

We now need to shift necessary files like `xcpp.data` which contains the binary representation of the file(s)
we want to include in our application. As of now this would contain all important files like Standard Headers,
Libraries etc coming out of emscripten's sysroot. Assuming we are still inside build we should do the following
```bash
cp xcpp.data _output/extensions/@jupyterlite/xeus/static
cp $PREFIX/lib/libclangCppInterOp.so _output/extensions/@jupyterlite/xeus/static
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Though we would always need to copy xcpp.data to a location that is accessible by Jupyter Lite (either _output/xeus/bin or _output/extensions/@jupyterlite/xeus/static that already have access to xcpp.js and xcpp.wasm .......

The second line here shifting libclangCppInterOp.so would only be required temporarily. This is only because JupyterLite doesn't deal with shared libs as expected as I think it expects static libs. Hence once we shift to emsdk 3.1.73 and can support a static lib (libclangCppInterOp.a) this would no longer be required !

Hence this is temporary.

```

Once the Jupyter Lite site has built you can test the website locally by executing
```bash
jupyter lite serve --XeusAddon.prefix=$PREFIX
```


## Trying it online

To try out xeus-cpp interactively in your web browser, just click on the binder link:
Expand Down
3 changes: 3 additions & 0 deletions include/xeus-cpp/xinterpreter_wasm.hpp
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,9 @@ namespace xcpp
wasm_interpreter();
virtual ~wasm_interpreter() = default;

private:

static std::vector<const char*> create_args();
anutosh491 marked this conversation as resolved.
Show resolved Hide resolved
};
}

Expand Down
11 changes: 9 additions & 2 deletions src/xinterpreter.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,7 @@ using Args = std::vector<const char*>;

void* createInterpreter(const Args &ExtraArgs = {}) {
Args ClangArgs = {/*"-xc++"*/"-v"}; // ? {"-Xclang", "-emit-llvm-only", "-Xclang", "-diagnostic-log-file", "-Xclang", "-", "-xc++"};
#ifndef EMSCRIPTEN
if (std::find_if(ExtraArgs.begin(), ExtraArgs.end(), [](const std::string& s) {
return s == "-resource-dir";}) == ExtraArgs.end()) {
std::string resource_dir = Cpp::DetectResourceDir();
Expand All @@ -42,6 +43,7 @@ void* createInterpreter(const Args &ExtraArgs = {}) {
ClangArgs.push_back("-isystem");
ClangArgs.push_back(CxxInclude.c_str());
}
#endif
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These instructions( DetectResourceDir and DetectSystemCompilerIncludePaths ) can never be put to use as they are based on exec which emscripten doesn't plan on supporting now or in future.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if we are okay having errors coming up in the console due to this. They lead to other problems anyways.

image

ClangArgs.insert(ClangArgs.end(), ExtraArgs.begin(), ExtraArgs.end());
// FIXME: We should process the kernel input options and conditionally pass
// the gpu args here.
Expand Down Expand Up @@ -73,6 +75,7 @@ namespace xcpp
static std::string get_stdopt()
{
// We need to find what's the C++ version the interpreter runs with.
#ifndef EMSCRIPTEN
const char* code = R"(
int __get_cxx_version () {
#if __cplusplus > 202302L
Expand All @@ -93,12 +96,14 @@ int __get_cxx_version () {
}
__get_cxx_version ()
)";

auto cxx_version = Cpp::Evaluate(code);
return std::to_string(cxx_version);
#else
constexpr int cxx_version = 20;
return std::to_string(cxx_version);
anutosh491 marked this conversation as resolved.
Show resolved Hide resolved
#endif
anutosh491 marked this conversation as resolved.
Show resolved Hide resolved
}


interpreter::interpreter(int argc, const char* const* argv) :
xmagics()
, p_cout_strbuf(nullptr)
Expand Down Expand Up @@ -357,7 +362,9 @@ __get_cxx_version ()

void interpreter::init_includes()
{
#ifndef EMSCRIPTEN
Cpp::AddIncludePath((xeus::prefix_path() + "/include/").c_str());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to go in createInterpreter as I suggested in previous comment.

Copy link
Collaborator Author

@anutosh491 anutosh491 Dec 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should be able to do without it but let's do the above if you think we would need that !

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We had that functionality before and I do not see anything that explains why we should drop it. I think we should drop it generally and solve the problem with parameters to the kernel. If we want that pleas update the commit message and we can drop.

Copy link
Collaborator Author

@anutosh491 anutosh491 Dec 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, maybe check this comment (#199 (comment))

So

  1. we anyways don't need it for the wasm case.
  2. I do not see any difference including it or not including for the non-wasm cases . I see the following locally with or without it.
 "/Users/anutosh491/micromamba/envs/xeus-cpp/bin/xcpp" -cc1 -triple arm64-apple-macosx14.0.0 -Wundef-prefix=TARGET_OS_ -Werror=undef-prefix -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -E -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name "<<< inputs >>>" -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=non-leaf -ffp-contract=on -fno-rounding-math -funwind-tables=1 -target-sdk-version=14.4 -fcompatibility-qualified-id-block-type-checking -fvisibility-inlines-hidden-static-local-var -fbuiltin-headers-in-system-modules -fdefine-target-os-macros -target-cpu apple-m1 -target-feature +zcm -target-feature +zcz -target-feature +v8.4a -target-feature +aes -target-feature +altnzcv -target-feature +ccdp -target-feature +complxnum -target-feature +crc -target-feature +dotprod -target-feature +fp-armv8 -target-feature +fp16fml -target-feature +fptoint -target-feature +fullfp16 -target-feature +jsconv -target-feature +lse -target-feature +neon -target-feature +pauth -target-feature +perfmon -target-feature +predres -target-feature +ras -target-feature +rcpc -target-feature +rdm -target-feature +sb -target-feature +sha2 -target-feature +sha3 -target-feature +specrestrict -target-feature +ssbs -target-abi darwinpcs -debugger-tuning=lldb -fdebug-compilation-dir=/Users/anutosh491/work/xeus-cpp/build5 -target-linker-version 951.9 -v -fcoverage-compilation-dir=/Users/anutosh491/work/xeus-cpp/build5 -resource-dir /Users/anutosh491/micromamba/envs/xeus-cpp/lib/clang/19 -isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1 -isystem /Library/Developer/CommandLineTools/usr/lib/clang/15.0.0/include -isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -isystem /Library/Developer/CommandLineTools/usr/include -isystem "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)" -include new -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -I /Users/anutosh491/micromamba/envs/xeus-cpp/include -internal-isystem /Users/anutosh491/micromamba/envs/xeus-cpp/bin/../include/c++/v1 -internal-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include -internal-isystem /Users/anutosh491/micromamba/envs/xeus-cpp/lib/clang/19/include -internal-externc-isystem /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -std=c++20 -fdeprecated-macro -ferror-limit 19 -stack-protector 1 -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fgnuc-version=4.2.1 -fno-implicit-modules -fskip-odr-check-in-gmf -fcxx-exceptions -fexceptions -fmax-type-align=16 -fcolor-diagnostics -fincremental-extensions -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o - -x c++ "<<< inputs >>>"
clang -cc1 version 19.1.2 based upon LLVM 19.1.2 default target arm64-apple-darwin23.5.0
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Users/anutosh491/micromamba/envs/xeus-cpp/lib/clang/19/include"
ignoring nonexistent directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/Library/Frameworks"
ignoring duplicate directory "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /Users/anutosh491/micromamba/envs/xeus-cpp/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1
 /Library/Developer/CommandLineTools/usr/lib/clang/15.0.0/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/usr/include
 /Users/anutosh491/micromamba/envs/xeus-cpp/bin/../include/c++/v1
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.

Hence I removed it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You won't see a difference with that command as the include path is added at a later stage than printing the invocation commands.

Whatever, if somebody wants to re-enable this, we can solve it in a more consistent way by adding a -I in the kernel.json.

#endif
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would end up giving up $MAMBA_ROOT_PREFIX/envs/xeus-cpp-wasm-host/include/ which is of no use to us as it's a local path web assembly would just want to ignore.

But even if we go for it, it would lead to path lookup errors for now.

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can go in createInterpreter as CxxSystemIncludes.push_back(xeus::prefix_path() + "/include/")

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm kinda confused as to why this should be treated as a system include rather than using AddIncludePath

Do we want to have something like -isystem /Users/anutosh491/micromamba/envs/xeus-cpp/include/ while building xeus-cpp for non wasm cases ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we won't be interested in the init_includes method as a whole for the wasm case, we could only have it for the non-wasm case at the top itself

    interpreter::interpreter(int argc, const char* const* argv) :
       .....
    {
        .....
        init_includes();
        init_preamble();
        init_magic();
    }

We could only enable it for the non wasm case rather than doing this.

        void interpreter::init_includes()
    {
#ifndef EMSCRIPTEN
        Cpp::AddIncludePath((xeus::prefix_path() + "/include/").c_str());
#endif
    }

The same applies for init_magics as we have the following (though I strongly believe the file one can be supported in the near future.)

    void interpreter::init_magic()
    {
#ifndef EMSCRIPTEN
        preamble_manager["magics"].get_cast<xmagics_manager>().register_magic("xassist", xassist());
        preamble_manager["magics"].get_cast<xmagics_manager>().register_magic("file", writefile());
#endif
    }

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm kinda confused as to why this should be treated as a system include rather than using AddIncludePath

Do we want to have something like -isystem /Users/anutosh491/micromamba/envs/xeus-cpp/include/ while building xeus-cpp for non wasm cases ?

Isn’t that folder containing other conda packages?

Copy link
Collaborator Author

@anutosh491 anutosh491 Dec 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I get it. Let's do one thing. As we don't expect the init_include, init_magic or init_preamble to work for starters.

Hence a place we could start with rather than addressing everything separately is this as what I've done in my latest commit.

#ifndef EMSCRIPTEN
        init_includes();
        init_preamble();
        init_magic();
#endif

And one by one whatever we expect to get working for eg

  1. introspection like ?std::vector
  2. the file magic

We could start separating those out. And the ones that we don't expect to work for eg xassist depends on curl and curl is something that won't be working for wasm as of now .... so these would still be kept to be undefined in case of a wasm build.

EDIT: Argh, playing with the CI a bit tells me that even the above might not be a great approach, hence reverted the changes. Can't think of a nice way to address this for now. Maybe let's keep it like this for now and make a point to improve in near future ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not doing what I suggested in the first place?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My doubt is do we get rid of the init_includes method overall and just shift the functionality to createInterpreter ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can go in createInterpreter as CxxSystemIncludes.push_back(xeus::prefix_path() + "/include/")

That' what I am asking in this PR.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That' what I am asking in this PR.

Actually you know what, the init_includes doesn't even play a big part as we think it is !!

That's because it's overlapping with the following in kernel.json.in

"-I", "@XEUS_CPP_INCLUDE_DIR@",
"-std=c++20"@XEUS_CPP_OMP@

So the location we are interested in is taken care of anyways as I see the following locally coming out of kernel.json

#include "..." search starts here:
#include <...> search starts here:
 /Users/anutosh491/micromamba/envs/xeus-cpp/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1
 /Library/Developer/CommandLineTools/usr/lib/clang/15.0.0/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include
 /Library/Developer/CommandLineTools/usr/include
 /Users/anutosh491/micromamba/envs/xeus-cpp/bin/../include/c++/v1
 /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.

}

void interpreter::init_preamble()
Expand Down
8 changes: 7 additions & 1 deletion src/xinterpreter_wasm.cpp
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,13 @@ namespace xcpp
{

wasm_interpreter::wasm_interpreter()
: interpreter(0, nullptr)
: interpreter(create_args().size(), create_args().data())
anutosh491 marked this conversation as resolved.
Show resolved Hide resolved
anutosh491 marked this conversation as resolved.
Show resolved Hide resolved
{
}

std::vector<const char*> wasm_interpreter::create_args()
anutosh491 marked this conversation as resolved.
Show resolved Hide resolved
{
static std::vector<const char*> Args = {"-Xclang", "-std=c++20"};
return Args;
}
anutosh491 marked this conversation as resolved.
Show resolved Hide resolved
}