2022-07-04 18:32:36 +00:00
|
|
|
import subprocess
|
2021-03-02 18:48:57 +00:00
|
|
|
|
|
|
|
import pytest
|
2018-10-16 13:31:00 +00:00
|
|
|
|
2022-09-22 01:42:26 +00:00
|
|
|
from pyodide_build.pywasmcross import (
|
2024-02-09 05:06:31 +00:00
|
|
|
CrossCompileArgs,
|
2022-09-22 01:42:26 +00:00
|
|
|
calculate_exports,
|
2023-03-17 00:00:51 +00:00
|
|
|
filter_objects,
|
2022-09-22 01:42:26 +00:00
|
|
|
get_cmake_compiler_flags,
|
2023-02-06 23:35:20 +00:00
|
|
|
handle_command_generate_args,
|
2024-02-09 05:06:31 +00:00
|
|
|
is_link_cmd,
|
2023-09-20 07:00:04 +00:00
|
|
|
replay_genargs_handle_dashI,
|
2022-09-22 01:42:26 +00:00
|
|
|
)
|
2018-10-16 13:31:00 +00:00
|
|
|
|
|
|
|
|
2023-01-30 04:35:18 +00:00
|
|
|
@pytest.fixture(scope="function")
|
|
|
|
def build_args():
|
2024-02-09 05:06:31 +00:00
|
|
|
yield CrossCompileArgs(
|
2023-01-30 04:35:18 +00:00
|
|
|
cflags="",
|
|
|
|
cxxflags="",
|
|
|
|
ldflags="",
|
|
|
|
target_install_dir="",
|
|
|
|
pythoninclude="python/include",
|
|
|
|
exports="whole_archive",
|
|
|
|
)
|
2021-03-02 18:48:57 +00:00
|
|
|
|
|
|
|
|
2024-02-09 05:06:31 +00:00
|
|
|
def generate_args(line: str, args: CrossCompileArgs, is_link_cmd: bool = False) -> str:
|
No replay (#2256)
Our package build process currently has a significant flaw: we first run setup.py, recording all compilation commands, then we rewrite these compilation commands to invoke emcc and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us.
However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command.
I also added a patch to fix the numpy feature detection for wasm so that we don't have to include _npyconfig.h and config.h, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream:
numpy/numpy#21154
This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior.
This is on top of #2238.
2022-03-13 18:39:06 +00:00
|
|
|
splitline = line.split()
|
2024-02-09 05:06:31 +00:00
|
|
|
res = handle_command_generate_args(splitline, args)
|
2022-09-13 04:19:44 +00:00
|
|
|
|
|
|
|
if res[0] in ("emcc", "em++"):
|
|
|
|
for arg in [
|
|
|
|
"-Werror=implicit-function-declaration",
|
|
|
|
"-Werror=mismatched-parameter-types",
|
|
|
|
"-Werror=return-type",
|
|
|
|
]:
|
|
|
|
assert arg in res
|
|
|
|
res.remove(arg)
|
|
|
|
|
2022-03-22 05:05:30 +00:00
|
|
|
if "-c" in splitline:
|
2023-01-30 04:35:18 +00:00
|
|
|
if "python/include" in res:
|
|
|
|
include_index = res.index("python/include")
|
|
|
|
del res[include_index]
|
|
|
|
del res[include_index - 1]
|
2022-03-22 05:05:30 +00:00
|
|
|
|
No replay (#2256)
Our package build process currently has a significant flaw: we first run setup.py, recording all compilation commands, then we rewrite these compilation commands to invoke emcc and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us.
However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command.
I also added a patch to fix the numpy feature detection for wasm so that we don't have to include _npyconfig.h and config.h, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream:
numpy/numpy#21154
This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior.
This is on top of #2238.
2022-03-13 18:39:06 +00:00
|
|
|
if is_link_cmd:
|
|
|
|
arg = "-Wl,--fatal-warnings"
|
|
|
|
assert arg in res
|
|
|
|
res.remove(arg)
|
|
|
|
return " ".join(res)
|
|
|
|
|
|
|
|
|
2023-01-30 04:35:18 +00:00
|
|
|
def test_handle_command(build_args):
|
|
|
|
args = build_args
|
2024-02-09 05:06:31 +00:00
|
|
|
assert handle_command_generate_args(["gcc", "-print-multiarch"], args) == [
|
No replay (#2256)
Our package build process currently has a significant flaw: we first run setup.py, recording all compilation commands, then we rewrite these compilation commands to invoke emcc and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us.
However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command.
I also added a patch to fix the numpy feature detection for wasm so that we don't have to include _npyconfig.h and config.h, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream:
numpy/numpy#21154
This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior.
This is on top of #2238.
2022-03-13 18:39:06 +00:00
|
|
|
"echo",
|
|
|
|
"wasm32-emscripten",
|
|
|
|
]
|
2022-09-13 04:19:44 +00:00
|
|
|
|
|
|
|
proxied_commands = {
|
|
|
|
"cc": "emcc",
|
|
|
|
"c++": "em++",
|
|
|
|
"gcc": "emcc",
|
|
|
|
"ld": "emcc",
|
|
|
|
"ar": "emar",
|
|
|
|
"ranlib": "emranlib",
|
|
|
|
"strip": "emstrip",
|
2022-09-22 01:42:26 +00:00
|
|
|
"cmake": "emcmake",
|
2022-09-13 04:19:44 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for cmd, proxied_cmd in proxied_commands.items():
|
2022-09-22 01:42:26 +00:00
|
|
|
assert generate_args(cmd, args).split()[0] == proxied_cmd
|
2022-09-13 04:19:44 +00:00
|
|
|
|
2020-06-28 18:24:40 +00:00
|
|
|
assert (
|
2022-07-26 06:48:36 +00:00
|
|
|
generate_args("gcc -c test.o -o test.so", args, True)
|
2021-02-06 07:58:12 +00:00
|
|
|
== "emcc -c test.o -o test.so"
|
2020-06-28 18:24:40 +00:00
|
|
|
)
|
2018-10-16 13:31:00 +00:00
|
|
|
|
2021-01-03 00:17:08 +00:00
|
|
|
# check cxxflags injection and cpp detection
|
2024-02-09 05:06:31 +00:00
|
|
|
args = CrossCompileArgs(
|
2021-01-03 15:37:44 +00:00
|
|
|
cflags="-I./lib2",
|
|
|
|
cxxflags="-std=c++11",
|
|
|
|
ldflags="-lm",
|
2023-01-30 04:35:18 +00:00
|
|
|
exports="whole_archive",
|
2021-01-03 15:37:44 +00:00
|
|
|
)
|
2021-01-03 00:17:08 +00:00
|
|
|
assert (
|
No replay (#2256)
Our package build process currently has a significant flaw: we first run setup.py, recording all compilation commands, then we rewrite these compilation commands to invoke emcc and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us.
However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command.
I also added a patch to fix the numpy feature detection for wasm so that we don't have to include _npyconfig.h and config.h, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream:
numpy/numpy#21154
This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior.
This is on top of #2238.
2022-03-13 18:39:06 +00:00
|
|
|
generate_args("gcc -I./lib1 -c test.cpp -o test.o", args)
|
2023-05-18 03:57:40 +00:00
|
|
|
== "em++ -I./lib1 -c test.cpp -o test.o -I./lib2 -std=c++11"
|
2021-01-03 00:17:08 +00:00
|
|
|
)
|
|
|
|
|
2018-10-16 13:31:00 +00:00
|
|
|
# check ldflags injection
|
2024-02-09 05:06:31 +00:00
|
|
|
args = CrossCompileArgs(
|
2021-12-20 19:26:27 +00:00
|
|
|
cflags="",
|
|
|
|
cxxflags="",
|
|
|
|
ldflags="-lm",
|
|
|
|
target_install_dir="",
|
2023-01-30 04:35:18 +00:00
|
|
|
exports="whole_archive",
|
2021-02-04 11:34:40 +00:00
|
|
|
)
|
2020-06-28 18:24:40 +00:00
|
|
|
assert (
|
2022-07-26 06:48:36 +00:00
|
|
|
generate_args("gcc -c test.o -o test.so", args, True)
|
2023-05-18 03:57:40 +00:00
|
|
|
== "emcc -c test.o -o test.so -lm"
|
2020-06-28 18:24:40 +00:00
|
|
|
)
|
2018-10-16 13:31:00 +00:00
|
|
|
|
2022-07-02 13:53:16 +00:00
|
|
|
# Test that repeated libraries are removed
|
2021-01-03 15:37:44 +00:00
|
|
|
assert (
|
2024-02-09 05:06:31 +00:00
|
|
|
generate_args("gcc test.o -lbob -ljim -ljim -lbob -o test.so", args, True)
|
|
|
|
== "emcc test.o -lbob -ljim -o test.so -lm"
|
2021-01-03 15:37:44 +00:00
|
|
|
)
|
|
|
|
|
2018-10-26 15:22:10 +00:00
|
|
|
|
2023-01-30 04:35:18 +00:00
|
|
|
def test_handle_command_ldflags(build_args):
|
2021-11-16 21:06:38 +00:00
|
|
|
# Make sure to remove unsupported link flags for wasm-ld
|
|
|
|
|
2023-01-30 04:35:18 +00:00
|
|
|
args = build_args
|
2021-11-16 21:06:38 +00:00
|
|
|
assert (
|
No replay (#2256)
Our package build process currently has a significant flaw: we first run setup.py, recording all compilation commands, then we rewrite these compilation commands to invoke emcc and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us.
However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command.
I also added a patch to fix the numpy feature detection for wasm so that we don't have to include _npyconfig.h and config.h, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream:
numpy/numpy#21154
This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior.
This is on top of #2238.
2022-03-13 18:39:06 +00:00
|
|
|
generate_args(
|
2022-07-26 06:48:36 +00:00
|
|
|
"gcc -Wl,--strip-all,--as-needed -Wl,--sort-common,-z,now,-Bsymbolic-functions -c test.o -o test.so",
|
2021-11-16 21:14:36 +00:00
|
|
|
args,
|
No replay (#2256)
Our package build process currently has a significant flaw: we first run setup.py, recording all compilation commands, then we rewrite these compilation commands to invoke emcc and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us.
However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command.
I also added a patch to fix the numpy feature detection for wasm so that we don't have to include _npyconfig.h and config.h, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream:
numpy/numpy#21154
This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior.
This is on top of #2238.
2022-03-13 18:39:06 +00:00
|
|
|
True,
|
2021-11-16 21:14:36 +00:00
|
|
|
)
|
2021-11-16 21:06:38 +00:00
|
|
|
== "emcc -Wl,-z,now -c test.o -o test.so"
|
|
|
|
)
|
|
|
|
|
|
|
|
|
2023-09-20 07:00:04 +00:00
|
|
|
def test_replay_genargs_handle_dashI(monkeypatch):
|
|
|
|
import sys
|
|
|
|
|
|
|
|
mock_prefix = "/mock_prefix"
|
|
|
|
mock_base_prefix = "/mock_base_prefix"
|
|
|
|
monkeypatch.setattr(sys, "prefix", mock_prefix)
|
|
|
|
monkeypatch.setattr(sys, "base_prefix", mock_base_prefix)
|
|
|
|
|
|
|
|
target_dir = "/target"
|
|
|
|
target_cpython_include = "/target/include/python3.11"
|
|
|
|
|
|
|
|
assert replay_genargs_handle_dashI("-I/usr/include", target_dir) is None
|
|
|
|
assert (
|
|
|
|
replay_genargs_handle_dashI(f"-I{mock_prefix}/include/python3.11", target_dir)
|
|
|
|
== f"-I{target_cpython_include}"
|
|
|
|
)
|
|
|
|
assert (
|
|
|
|
replay_genargs_handle_dashI(
|
|
|
|
f"-I{mock_base_prefix}/include/python3.11", target_dir
|
|
|
|
)
|
|
|
|
== f"-I{target_cpython_include}"
|
|
|
|
)
|
|
|
|
|
|
|
|
|
2023-01-30 04:35:18 +00:00
|
|
|
def test_conda_unsupported_args(build_args):
|
2022-03-08 05:51:20 +00:00
|
|
|
# Check that compile arguments that are not supported by emcc and are sometimes
|
2021-10-27 07:35:59 +00:00
|
|
|
# used in conda are removed.
|
2023-01-30 04:35:18 +00:00
|
|
|
args = build_args
|
2024-02-09 05:06:31 +00:00
|
|
|
assert generate_args(
|
|
|
|
"gcc -c test.o -B /compiler_compat -o test.so", args, True
|
|
|
|
) == ("emcc -c test.o -o test.so")
|
2021-02-04 11:34:40 +00:00
|
|
|
|
2024-02-09 05:06:31 +00:00
|
|
|
assert generate_args("gcc -c test.o -Wl,--sysroot=/ -o test.so", args, True) == (
|
No replay (#2256)
Our package build process currently has a significant flaw: we first run setup.py, recording all compilation commands, then we rewrite these compilation commands to invoke emcc and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us.
However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command.
I also added a patch to fix the numpy feature detection for wasm so that we don't have to include _npyconfig.h and config.h, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream:
numpy/numpy#21154
This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior.
This is on top of #2238.
2022-03-13 18:39:06 +00:00
|
|
|
"emcc -c test.o -o test.so"
|
|
|
|
)
|
2021-10-27 07:35:59 +00:00
|
|
|
|
2021-02-04 11:34:40 +00:00
|
|
|
|
2023-03-17 00:00:51 +00:00
|
|
|
@pytest.mark.parametrize(
|
|
|
|
"line, expected",
|
|
|
|
[
|
|
|
|
([], []),
|
|
|
|
(
|
|
|
|
[
|
|
|
|
"obj1.o",
|
|
|
|
"obj2.o",
|
|
|
|
"slib1.so",
|
|
|
|
"slib2.so",
|
|
|
|
"lib1.a",
|
|
|
|
"lib2.a",
|
|
|
|
"-o",
|
|
|
|
"test.so",
|
|
|
|
],
|
|
|
|
["obj1.o", "obj2.o", "lib1.a", "lib2.a"],
|
|
|
|
),
|
|
|
|
(
|
|
|
|
["@dir/link.txt", "obj1.o", "obj2.o", "test.so"],
|
|
|
|
["@dir/link.txt", "obj1.o", "obj2.o"],
|
|
|
|
),
|
|
|
|
],
|
|
|
|
)
|
|
|
|
def test_filter_objects(line, expected):
|
|
|
|
assert filter_objects(line) == expected
|
|
|
|
|
|
|
|
|
2022-07-31 10:00:45 +00:00
|
|
|
@pytest.mark.xfail(reason="FIXME: emcc is not available during test")
|
2022-07-04 18:32:36 +00:00
|
|
|
def test_exports_node(tmp_path):
|
|
|
|
template = """
|
|
|
|
int l();
|
|
|
|
|
|
|
|
__attribute__((visibility("hidden")))
|
|
|
|
int f%s() {
|
|
|
|
return l();
|
|
|
|
}
|
|
|
|
|
|
|
|
__attribute__ ((visibility ("default")))
|
|
|
|
int g%s() {
|
|
|
|
return l();
|
|
|
|
}
|
|
|
|
|
|
|
|
int h%s(){
|
|
|
|
return l();
|
|
|
|
}
|
|
|
|
"""
|
|
|
|
(tmp_path / "f1.c").write_text(template % (1, 1, 1))
|
|
|
|
(tmp_path / "f2.c").write_text(template % (2, 2, 2))
|
|
|
|
subprocess.run(["emcc", "-c", tmp_path / "f1.c", "-o", tmp_path / "f1.o", "-fPIC"])
|
|
|
|
subprocess.run(["emcc", "-c", tmp_path / "f2.c", "-o", tmp_path / "f2.o", "-fPIC"])
|
|
|
|
assert set(calculate_exports([str(tmp_path / "f1.o")], True)) == {"g1", "h1"}
|
|
|
|
assert set(
|
|
|
|
calculate_exports([str(tmp_path / "f1.o"), str(tmp_path / "f2.o")], True)
|
|
|
|
) == {
|
|
|
|
"g1",
|
|
|
|
"h1",
|
|
|
|
"g2",
|
|
|
|
"h2",
|
|
|
|
}
|
|
|
|
# Currently if the object file contains bitcode we can't tell what the
|
|
|
|
# symbol visibility is.
|
|
|
|
subprocess.run(
|
|
|
|
["emcc", "-c", tmp_path / "f1.c", "-o", tmp_path / "f1.o", "-fPIC", "-flto"]
|
|
|
|
)
|
|
|
|
assert set(calculate_exports([str(tmp_path / "f1.o")], True)) == {"f1", "g1", "h1"}
|
2022-09-22 01:42:26 +00:00
|
|
|
|
|
|
|
|
|
|
|
def test_get_cmake_compiler_flags():
|
|
|
|
cmake_flags = " ".join(get_cmake_compiler_flags())
|
|
|
|
|
|
|
|
compiler_flags = (
|
|
|
|
"CMAKE_C_COMPILER",
|
|
|
|
"CMAKE_CXX_COMPILER",
|
|
|
|
"CMAKE_C_COMPILER_AR",
|
|
|
|
"CMAKE_CXX_COMPILER_AR",
|
|
|
|
)
|
|
|
|
|
|
|
|
for compiler_flag in compiler_flags:
|
|
|
|
assert f"-D{compiler_flag}" in cmake_flags
|
|
|
|
|
|
|
|
emscripten_compilers = (
|
|
|
|
"emcc",
|
|
|
|
"em++",
|
|
|
|
"emar",
|
|
|
|
)
|
|
|
|
|
|
|
|
for emscripten_compiler in emscripten_compilers:
|
|
|
|
assert emscripten_compiler not in cmake_flags
|
2022-09-30 02:06:41 +00:00
|
|
|
|
|
|
|
|
2023-01-30 04:35:18 +00:00
|
|
|
def test_handle_command_cmake(build_args):
|
|
|
|
args = build_args
|
2024-02-09 05:06:31 +00:00
|
|
|
assert "--fresh" in handle_command_generate_args(["cmake", "./"], args)
|
2023-01-13 17:41:29 +00:00
|
|
|
|
|
|
|
build_cmd = ["cmake", "--build", "." "--target", "target"]
|
2024-02-09 05:06:31 +00:00
|
|
|
assert handle_command_generate_args(build_cmd, args) == build_cmd
|
2023-01-13 17:41:29 +00:00
|
|
|
|
|
|
|
|
2024-02-09 05:06:31 +00:00
|
|
|
def test_is_link_cmd():
|
|
|
|
assert is_link_cmd(["test.so"])
|
|
|
|
assert is_link_cmd(["test.so.1.2.3"])
|
|
|
|
assert not is_link_cmd(["test", "test.a", "test.o", "test.c", "test.cpp", "test.h"])
|