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

[ebo]

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]

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]

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]

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]

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]

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](https://www.python.org/dev/peps/pep-0621/) 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 [53ee7b2..f6a35e6](https://github.com/machinekit/machinekit-hal/compare/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]

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