search

HARPLab / DReyeVR

VR driving 🚙 + eye tracking 👀 simulator based on CARLA for driving interaction research
https://arxiv.org/abs/2201.01931
MIT License
139 stars 37 forks source link

Problems with make PythonAPI #159

Open edugh02 opened 2 months ago

edugh02 commented 2 months ago

Hi, i have problems trying to do the make PythonAPI comand in my x64 Native Tools Command Prompt for VS2019 I'm using:

And I also have changed install_xercesc.bat changing the xerces version from 3.2.3 to 3.2.5, and also the same with install_zlib.bat changing to zlib version 1.3.1

I get the following error:

`-[BuildOSM2ODR]: [Batch params]: --build --all Cloning into 'C:\TFG\carla\Build\om2odr-source'... remote: Enumerating objects: 1438389, done. remote: Counting objects: 100% (13086/13086), done. remote: Compressing objects: 100% (1773/1773), done. Receiving objects: 100% (1438389/1438389), 993.69 MiB | 7.85 MiB/s, done.sed 1425303Receiving objects: 100% (1438389/1438389), 991.69 MiB | 9.68 MiB/s

Resolving deltas: 100% (1224119/1224119), done. Updating files: 100% (108359/108359), done. Updating files: 100% (103225/103225), done. Note: switching to 'ee0c2b9241fef5365a6bc044ac82e6580b8ce936'.

You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example:

git switch -c

Or undo this operation with:

git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at ee0c2b9241f Removed debug warnings -- Setting build type to 'Release' as none was specified. CMake Warning (dev) at CMakeLists.txt:23 (project): cmake_minimum_required() should be called prior to this top-level project() call. Please see the cmake-commands(7) manual for usage documentation of both commands. This warning is for project developers. Use -Wno-dev to suppress it.

-- Selecting Windows SDK version 10.0.22000.0 to target Windows 10.0.22631. -- The C compiler identification is MSVC 19.29.30154.0 -- The CXX compiler identification is MSVC 19.29.30154.0 -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Deprecation Warning at CMakeLists.txt:25 (cmake_minimum_required): Compatibility with CMake < 3.5 will be removed from a future version of CMake.

Update the VERSION argument value or use a ... suffix to tell CMake that the project does not need compatibility with older versions.

-- CMAKE_BINARY_DIR: C:/TFG/carla/Build/osm2odr-visualstudio -- CMAKE_SOURCE_DIR: C:/TFG/carla/Build/om2odr-source

-- Platform: -- Host: Windows-10.0.22631 AMD64 -- Target: Windows-10.0.22631 AMD64 -- CMake: 3.29.0 -- CMake generator: Visual Studio 16 2019 -- CMake build tool: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/MSBuild/Current/Bin/MSBuild.exe -- Compiler: MSVC 19.29.30154.0

CMake Error at C:/Program Files/CMake/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Failed to find XercesC (missing: XercesC_VERSION) Call Stack (most recent call first): C:/Program Files/CMake/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE) C:/Program Files/CMake/share/cmake-3.29/Modules/FindXercesC.cmake:112 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:71 (find_package)

-- Configuring incomplete, errors occurred! Microsoft (R) Build Engine versión 16.11.2+f32259642 para .NET Framework Copyright (C) Microsoft Corporation. Todos los derechos reservados.

MSBUILD : error MSB1009: El archivo de proyecto no existe. Modificador: install.vcxproj -[BuildOSM2ODR]: OSM2ODR has been successfully installed in "C:\TFG\carla\PythonAPI\carla\dependencies\" -[BuildPythonAPI]: [Batch params]: --py3 Building Python API for Python 3. compiling:

-[BuildPythonAPI]: Carla lib for python has been successfully installed in "C:\TFG\carla\PythonAPI\carla\dist"!`

ajdroid commented 2 months ago

This is a carla build issue. See here for possible solutions: https://github.com/carla-simulator/carla/issues/3320

edugh02 commented 2 months ago

I've upgraded from carla 0.9.13 to 0.9.15 and python 3.7.0 to Python 3.12.2 and i fixed it. But now i have the following error: Once i have launched carla with make launch, i try to generete traffic but i have this problem:

C:\TFG\carla\PythonAPI\examples>pip3 install -r requirements.txt Defaulting to user installation because normal site-packages is not writeable Ignoring numpy: markers 'python_version < "3.0"' don't match your environment Collecting future (from -r requirements.txt (line 1)) Using cached future-1.0.0-py3-none-any.whl.metadata (4.0 kB) Collecting numpy==1.18.4 (from -r requirements.txt (line 3)) Using cached numpy-1.18.4.zip (5.4 MB) Installing build dependencies ... done Getting requirements to build wheel ... done Preparing metadata (pyproject.toml) ... error error: subprocess-exited-with-error

× Preparing metadata (pyproject.toml) did not run successfully. │ exit code: 1 ╰─> [92 lines of output] Running from numpy source directory.

:461: UserWarning: Unrecognized setuptools command, proceeding with generating Cython sources and expanding templates C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py:75: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. required_version = LooseVersion('0.29.14') C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py:77: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. if LooseVersion(cython_version) < required_version: performance hint: _common.pyx:261:19: Exception check after calling 'random_func' will always require the GIL to be acquired. Declare 'random_func' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:285:19: Exception check after calling 'random_func' will always require the GIL to be acquired. Declare 'random_func' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:308:50: Exception check after calling 'random_func' will always require the GIL to be acquired. Declare 'random_func' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:411:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:448:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:490:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:573:36: Exception check after calling 'f0' will always require the GIL to be acquired. Declare 'f0' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:577:36: Exception check after calling 'f1' will always require the GIL to be acquired. Declare 'f1' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:581:36: Exception check after calling 'f2' will always require the GIL to be acquired. Declare 'f2' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:585:36: Exception check after calling 'f3' will always require the GIL to be acquired. Declare 'f3' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:617:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:652:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:687:63: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:727:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:756:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:874:40: Exception check after calling 'f0' will always require the GIL to be acquired. Declare 'f0' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:878:40: Exception check after calling 'fd' will always require the GIL to be acquired. Declare 'fd' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:882:41: Exception check after calling 'fdd' will always require the GIL to be acquired. Declare 'fdd' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:887:40: Exception check after calling 'fi' will always require the GIL to be acquired. Declare 'fi' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:891:41: Exception check after calling 'fdi' will always require the GIL to be acquired. Declare 'fdi' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:895:38: Exception check after calling 'fiii' will always require the GIL to be acquired. Declare 'fiii' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:930:31: Exception check after calling 'f' will always require the GIL to be acquired. Declare 'f' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _common.pyx:972:32: Exception check after calling 'f1' will always require the GIL to be acquired. Declare 'f1' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. performance hint: _generator.pyx:811:41: Exception check after calling '_shuffle_int' will always require the GIL to be acquired. Possible solutions: 1. Declare '_shuffle_int' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. 2. Use an 'int' return type on '_shuffle_int' to allow an error code to be returned. performance hint: _generator.pyx:840:45: Exception check after calling '_shuffle_int' will always require the GIL to be acquired. Possible solutions: 1. Declare '_shuffle_int' as 'noexcept' if you control the definition and you're sure you don't want the function to raise exceptions. 2. Use an 'int' return type on '_shuffle_int' to allow an error code to be returned. Error compiling Cython file: ------------------------------------------------------------ ... for i in range(1, RK_STATE_LEN): self.rng_state.key[i] = val[i] self.rng_state.pos = i self._bitgen.state = &self.rng_state self._bitgen.next_uint64 = &mt19937_uint64 ^ ------------------------------------------------------------ _mt19937.pyx:138:35: Cannot assign type 'uint64_t (*)(void *) except? -1 nogil' to 'uint64_t (*)(void *) noexcept nogil'. Exception values are incompatible. Suggest adding 'noexcept' to the type of the value being assigned. Processing numpy/random\_bounded_integers.pxd.in Processing numpy/random\mtrand.pyx Processing numpy/random\_bit_generator.pyx Processing numpy/random\_bounded_integers.pyx.in Processing numpy/random\_common.pyx Processing numpy/random\_generator.pyx Processing numpy/random\_mt19937.pyx Traceback (most recent call last): File "C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py", line 238, in main() File "C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py", line 234, in main find_process_files(root_dir) File "C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py", line 225, in find_process_files process(root_dir, fromfile, tofile, function, hash_db) File "C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py", line 191, in process processor_function(fromfile, tofile) File "C:\Users\Admin\AppData\Local\Temp\pip-install-njerfvbr\numpy_6baaa279996548228e9198dfbab85a14\tools\cythonize.py", line 80, in process_pyx subprocess.check_call( File "C:\Program Files\Python312\Lib\subprocess.py", line 413, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['C:\\Program Files\\Python312\\python.exe', '-m', 'cython', '-3', '--fast-fail', '-o', '_mt19937.c', '_mt19937.pyx']' returned non-zero exit status 1. Cythonizing sources Traceback (most recent call last): File "C:\Program Files\Python312\Lib\site-packages\pip\_vendor\pyproject_hooks\_in_process\_in_process.py", line 353, in main() File "C:\Program Files\Python312\Lib\site-packages\pip\_vendor\pyproject_hooks\_in_process\_in_process.py", line 335, in main json_out['return_val'] = hook(**hook_input['kwargs']) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Program Files\Python312\Lib\site-packages\pip\_vendor\pyproject_hooks\_in_process\_in_process.py", line 149, in prepare_metadata_for_build_wheel return hook(metadata_directory, config_settings) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "C:\Users\Admin\AppData\Local\Temp\pip-build-env-7zqc9j08\overlay\Lib\site-packages\setuptools\build_meta.py", line 366, in prepare_metadata_for_build_wheel self.run_setup() File "C:\Users\Admin\AppData\Local\Temp\pip-build-env-7zqc9j08\overlay\Lib\site-packages\setuptools\build_meta.py", line 487, in run_setup super().run_setup(setup_script=setup_script) File "C:\Users\Admin\AppData\Local\Temp\pip-build-env-7zqc9j08\overlay\Lib\site-packages\setuptools\build_meta.py", line 311, in run_setup exec(code, locals()) File "", line 488, in File "", line 469, in setup_package File "", line 275, in generate_cython RuntimeError: Running cythonize failed! [end of output] note: This error originates from a subprocess, and is likely not a problem with pip. error: metadata-generation-failed × Encountered error while generating package metadata. ╰─> See above for output. note: This is an issue with the package mentioned above, not pip. hint: See above for details.