search

machinekit / machinekit-hal

Universal framework for machine control based on Hardware Abstraction Layer principle
https://www.machinekit.io
Other
109 stars 63 forks source link

build failed with "PYPROJECT_BUILD using the following names: pyproject-build" #365

Open ebo opened 2 years ago

ebo commented 2 years ago

I am trying to build machinekit-hal on an PRi3 (buster) and running "cmake -S . -B ./build" produces the error "PYPROJECT_BUILD using the following names: pyproject-build" on line 32 of src/libraries/ads7828/CMakeLists.txt

I have installed pyproject (1.3.1), but it still produces the error. Any suggestions on how to work around this?

cerna commented 2 years ago

The PYPROJECT_BUILD variable is populated by searching the environment (${PATH}) for the pyproject-build, which is itself an entrypoint script created from https://github.com/pypa/build/blob/96f9188ad181907fbd3e0efdf32dd3dc959d39c3/setup.cfg#L41 of the Build project available from PyPi or as Debian package.

However, even though I created the necessary packages for Debian 10 Buster in Machinekit's Debian repository, I boned something up during the last stages of CMake retrofit, and Machinekit-HAL on Debian Buster become unrunnable. (I can point to the diff if you are interested.) So the supported version is the current stable - Bullseye.

ebo commented 2 years ago

I've spent days trying to get either a Buster or Bullseye version running. I'll go back and take another poke at Bullseye. At this point I do not care about the version, just want to get something working on the testbench.

ebo commented 2 years ago

Thanks to the 'build' pointer. Once I got that installed I was then able to systematically install all the required missing packages. As a note, a few sentences on this requirement + a requirements.txt would be helpful. As would a note on the Getting-Started page on Buster being unstable.

As a note, I was not able to get a clean Bullseye to boot on my test-bench (which has an RPi with a touchscreen). So, I'm currently building with Buster. So, please post the diff. I'll poke around and try to figure out why Bullseye is going into never-never-land after auto-resizing. Any suggestions appreciated, but I know that I'm in the dreaded abyss of poking at the OS.

Thanks again.

cerna commented 2 years ago

There are few more dependencies on executables required during the build process and there are still the requirements for the libraries. For Debian (and children) there is the mk-build-deps command to install them, but from the perspective of different distros, that will need to be documented. I think it is one more issue on the machinekit/machinekit-docs#327 plate.

I don't think requirements.txt file would be the best place, as the build is not a Python package. There are now Python packages inside (basically every little Python module is a package), but these use the PEP621 to declare dependencies (or will, after I find the time to go through them and add it [needed a little break from it all]).

The diff is between 53ee7b2b648d9377f7dbf77e0ca8d4322b560389..f6a35e60b67194623f7be134e2abee1681f18d3a, I think, sorry, I will check tomorrow for sure. The issue is happening during the runtime loading of the HAL module (the managed_hal module library). It probably dies and I am not sure on what.

ebo commented 2 years ago

right... I will try to look into this this weekend as well.

On Jan 20 2022 4:10 PM, cerna wrote:

There are few more dependencies on executables required during the build process and there are still the requirements for the libraries. For Debian (and children) there is the mk-build-deps command to install them, but from the perspective of different distros, that will need to be documented. I think it is one more issue on the machinekit/machinekit-docs#327 plate.

I don't think requirements.txt file would be the best place, as the build is not a Python package. There are now Python packages inside (basically every little Python module is a package), but these use the PEP621 to declare dependencies (or will, after I find the time to go through them and add it [needed a little break from it all]).

The diff is between 53ee7b2b648d9377f7dbf77e0ca8d4322b560389..f6a35e60b67194623f7be134e2abee1681f18d3a, I think, sorry, I will check tomorrow for sure. The issue is happening during the runtime loading of the HAL module (the managed_hal module library). It probably dies and I am not sure on what.

summerlotus513 commented 2 years ago

when i build on ubuntu18.04 LTS, i also see the problem. update my ubuntu to 20.04 LTS, it work