Problems with make PythonAPI

[edugh02]

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

• Windows 11
• Carla 0.9.13
• Visual Studio 16 2019
• Python 3.7.0
• Pip & Pip3 24.0
• GNU Make 3.81
• Cmake 3.29.0

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:

• source/libcarla/libcarla.cpp
  C:\Program Files\Python37\lib\distutils\dist.py:274: UserWarning: Unknown distribution option: 'long_description_content_type'
  warnings.warn(msg)
  running bdist_egg
  running egg_info
  writing source\carla.egg-info\PKG-INFO
  writing dependency_links to source\carla.egg-info\dependency_links.txt
  writing top-level names to source\carla.egg-info\top_level.txt
  reading manifest file 'source\carla.egg-info\SOURCES.txt'
  writing manifest file 'source\carla.egg-info\SOURCES.txt'
  installing library code to build\bdist.win-amd64\egg
  running install_lib
  running build_py
  running build_ext
  building 'carla.libcarla' extension
  C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX86\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MT -Idependencies/include "-IC:\Program Files\Python37\include" "-IC:\Program Files\Python37\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\ATLMFC\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include" "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\cppwinrt" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\ATLMFC\include" "-IC:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include" "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\include\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.22000.0\cppwinrt" /EHsc /Tpsource/libcarla/libcarla.cpp /Fobuild\temp.win-amd64-3.7\Release\source/libcarla/libcarla.obj /experimental:external /external:W0 /external:I dependencies/include/system /DBOOST_ALL_NO_LIB /DBOOST_PYTHON_STATIC_LIB /DBOOST_ERROR_CODE_HEADER_ONLY /D_WIN32_WINNT=0x0600 /DHAVE_SNPRINTF /DLIBCARLA_WITH_PYTHON_SUPPORT -DLIBCARLA_IMAGE_WITH_PNG_SUPPORT=true /MD
  cl : Línea de comandos warning D9025 : invalidando '/MT' con '/MD'
  libcarla.cpp
  C:\TFG\carla\PythonAPI\carla\source\libcarla\OSM2ODR.cpp(7): fatal error C1083: No se puede abrir el archivo incluir: 'OSM2ODR.h': No such file or directory
  error: command 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX86\x64\cl.exe' failed with exit status 2

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

[ajdroid]

This is a carla build issue. See here for possible solutions: carla-simulator/carla#3320

[edugh02]

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 <module>
      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 <module>
      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 "<string>", line 488, in <module>
    File "<string>", line 469, in setup_package
    File "<string>", 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.