New build system introduced, testing and feedback needed

[mfs12]

Hey community,

the PanelDue project decided to move away from an Eclipse based build system to a cmake based. Reasons for this are

• headless builds
• support for automated builds
• better support for different IDEs
• staying cross-platform
• the possibility to integrate better with github
• less resources
• lightweight defined build environments in docker containers
• extensible modular build system

As my development platform is Linux I couldn't test on other OSs. MacOS I might be fine because it's a Unix platform as well.

But I definitely need some feedback about the windows platform.

I am also very interested in feedback about the build instructions which you can find in the Readme.md.

[mfs12]

Check the link if you want to know which IDEs cmake supports.

https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html

[oliof]

@mfs12 the submodule is defined as an ssh target, which breaks for people that want to check out the code anonymously via http.

[oliof]

Detection of the build tools goes awry in WSL2 on Windows 11

PanelDueFirmware$ echo $CXX
/mnt/c/Program Files (x86)/GNU Tools ARM Embedded/8 2018-q4-major/bin/arm-none-eabi-g++.exe
PanelDueFirmware$ echo $CC
/mnt/c/Program Files (x86)/GNU Tools ARM Embedded/8 2018-q4-major/bin/arm-none-eabi-gcc.exe
PanelDueFirmware$ cmake -B build -DDEVICE=5.0i .
ARM-NONE-EABI GCC found: /mnt/c/Program Files (x86)/GNU Tools ARM Embedded/8 2018-q4-major/bin/arm-none-eabi-gcc.exe
ARM-NONE-EABI GCC Path: /mnt/c/Program Files (x86)/GNU Tools ARM Embedded/8 2018-q4-major/bin
ARM-NONE-EABI Cross Compile: arm-none-eabi-
Toolchain C_FLAGS: --param max-inline-insns-single=500 -mlong-calls -ffunction-sections -fdata-sections -fno-exceptions -fsingle-precision-constant -Wall -Wextra -Wundef -Wdouble-promotion -Wno-expansion-to-defined -std=gnu99
Toolchain CXX_FLAGS: --param max-inline-insns-single=500 -mlong-calls -ffunction-sections -fdata-sections -fno-exceptions -fsingle-precision-constant -Wall -Wextra -Wundef -Wdouble-promotion -Wno-expansion-to-defined -std=gnu++17 -fno-threadsafe-statics -fno-rtti
Toolchain ASM_FLAGS: --param max-inline-insns-single=500 -mlong-calls -ffunction-sections -fdata-sections -fno-exceptions -fsingle-precision-constant -Wall -Wextra -Wundef -Wdouble-promotion -Wno-expansion-to-defined
Toolchain LD_FLAGS:
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:11 (project):
  The CMAKE_C_COMPILER:
 
    arm-none-eabi-gcc
 
  is not a full path and was not found in the PATH.
 
  Tell CMake where to find the compiler by setting either the environment
  variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
  the compiler, or to the compiler name if it is in the PATH.
 
 
CMake Error at CMakeLists.txt:11 (project):
  The CMAKE_CXX_COMPILER:
 
    arm-none-eabi-g++
 
  is not a full path and was not found in the PATH.
 
  Tell CMake where to find the compiler by setting either the environment
  variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
  to the compiler, or to the compiler name if it is in the PATH.
 
 
-- Configuring incomplete, errors occurred!
See also "/mnt/c/Users/Harald Wagener/PanelDueFirmware/build/CMakeFiles/CMakeOutput.log".
See also "/mnt/c/Users/Harald Wagener/PanelDueFirmware/build/CMakeFiles/CMakeError.log".
PanelDueFirmware$
 

Setting the environment variables, or adding /mnt/c/Program Files (x86)/GNU Tools ARM Embedded/8 2018-q4-major/bin/ to the PATH does not solve the issue despite CMakes professions.

[mfs12]

@oliof i think it drops somehow the file extension "exe" and therefore doesn't find it. Probably something is going wrong in the toolchain detection.

[oliof]

@mfs12 I fixed it by installing the gnu-arm-eabi-gcc packages in Ubuntu again (this wasn't needed before, but I'll live).

More notes:

• CMake needs to be at least version 3.19 to support REAL_PATH subcommand. This should be pointed out in the dependency documentation. Ubuntu 20.04 (LTS release) is on version 3.16 (but kitware offers an upstream repo to get latest cmake, so this is barely an inconvenience)
• with compiler and cmake sorted out, I run into an error in the end:

[ 94%] Linking CXX executable paneldue.elf
arm-none-eabi-g++: error: Wagener/PanelDueFirmware/src/ASF/sam/utils/linker_scripts/sam4s/sam4s4/gcc/flash.ld: No such file or directory
make[2]: *** [CMakeFiles/paneldue.elf.dir/build.make:866: paneldue.elf] Error 1
make[2]: Leaving directory '/mnt/c/Users/Harald Wagener/PanelDueFirmware/build'
make[1]: *** [CMakeFiles/Makefile2:156: CMakeFiles/paneldue.elf.dir/all] Error 2
make[1]: Leaving directory '/mnt/c/Users/Harald Wagener/PanelDueFirmware/build'
make: *** [Makefile:91: all] Error 2
make: Leaving directory '/mnt/c/Users/Harald Wagener/PanelDueFirmware/

I assume this is due to spaces in the directory path -- generated build files should handle this gracefully.

EDIT: indeed, fixing build/CMakeFiles/paneldue.elf.dir/link.txt by escaping the space in the home directory name allows the build to complete.

[oliof]

And here is the tiniest pull request to eliminate a compiler warning: https://github.com/Duet3D/PanelDueFirmware/pull/177

oliof opened this pull request 13 Aug 2021, 10:14 in Duet3D/PanelDueFirmware

closed Eliminate compiler warning in FlashStorage.cpp #177

[mfs12]

Hey @oliof could you test the updated version on you windows machine?

https://github.com/Duet3D/PanelDueFirmware/pull/179

mfs12 opened this pull request 14 Aug 2021, 10:22 in Duet3D/PanelDueFirmware

closed Cmake improvements #179

[resam]

Seems to compile fine on latest macOS:

brew install gcc-arm-embedded
 
mkdir build
cd build
cmake -DDEVICE=v2-5.0 ..
make -j 4

(compiles everything, but plenty of warnings)

It produces a paneldue.bin with 144kB - which looks reasonable compared to the most recent official release binaries.

[oozeBot]

We'd love to see a quick tutorial on this from someone who has been successful building it on Windows. This was something we tried to tackle today with no success. Thanks

[oliof]

@oozebot I successfully did that, see the discussion at https://github.com/Duet3D/PanelDueFirmware/pull/179. You may need to pull that PR into your local repo to successfully build as it's not committed yet (or check out https://github.com/mfs12/PanelDueFirmware/tree/cmake-improvements).

1. If you don't have the GNU ARM Compiler and Build Tools installed yet, follow steps 1 and 3 from the RRF Build Instructions. I did re-use the 2018-q4 release but
2. Install CMake from the CMake Download Page. This replaces step 2 in the build instructions mentioned above.
3. Make sure to add the directories the binaries end up in to your Path.
4. Using Powershell, check you can find make, rm using (Get-Command make).Path and (Get-Command rm).Path.
5. Generate the build files running make -G "Unix Makefiles" -B build -DDEVICE="5.0i" -DCROSS_COMPILE="C:/Program\ Files\ (x86)/GNU\ Tools\ ARM\ Embedded/8\ 2018-q4-major/bin/arm-none-eabi-"(adjusting the value for-DCROSS_COMPILE parameter to your version and install path and the value for -DDEVICE for the PanelDue you want to build for).
6. Build the binary running make -C build all (you can run this with -j4 -O for maximum parallelism)

And that should be it.

@mfs12 I think it might be a good idea to follow the RRF change of moving the build instructions to the GitHub wiki and replacing both BuildInstructions.md (outdated now) and the Development section in Readme.md (more current).

mfs12 opened this pull request 14 Aug 2021, 10:22 in Duet3D/PanelDueFirmware

closed Cmake improvements #179

[mfs12]

Hey @oliof and @oozeBot,

I updated the readme file accordingly.

Updated the master branch https://github.com/duet3d/PanelDueFirmware/tree/master with fixes from @oliof and better documentation.

Feedback on the documentation is very welcome so people will be able to setup things as quick as possible.

[mfs12]

And what's really a bummer is the path handling for the CROSS_COMPILE variable on windows. If you have any good solutions for that I want to learn about them.

[oliof]

I can confirm that a clean checkout of PanelDueFirmware master branch builds cleanly on Windows now.

Will this build environment also come to RepRapFirmware?

[mfs12]

Will this build environment also come to RepRapFirmware?

This is still unclear. It depends on the experiences we collect with paneldue.

[oliof]

You have my vote of confidence (-:

And also let me point out that when I implemented the Colinear Tripteron kinematics, I resorted to building new versions of RepRapFirmware with the Makefiles Eclipse generated to relieve my anemic machine from running Eclipse all the time. So it's possible and desirable (-:

[gloomyandy]

This is probably sacrilege but I find using cmake overly complex and much prefer good old make. cmake is great when it works, but when there is a problem it can be very hard to identify what is the cause. The LPC and STM32 builds of RRF both use make, for the recent ESP32 version of the Duet WiFi software I used cmake (to fit in with the espressif build system), it is way more complex and hard to debug than the corresponding make system I use to build the ESP8266 version. Maybe I'm just too old school, but having watched many software projects disappear down a rat hole of a "new improved build system", sometimes simple is best.

[mfs12]

@gloomyandy, settting cmake up i stumbled also in quite some pitfalls. although i think the found solution is quite handy but still not perfect. but neither is make, it also has a lot of pitfalls from my experience.

But once either of them is working things should be ok.

So far we are living with eclipse build file generation, which is even harder to debug compared to make and cmake.

What convinced me to use cmake is the support for different IDEs, I hope this will lower the bar to build and develop the project.

Let's give it a shot.

[mfs12]

@gloomyandy said in New build system introduced, testing and feedback needed:

The LPC and STM32 builds of RRF both use make

Can you point me to the repository? Eventually it would be an option to port your solution to RRF.

[jay_s_uk]

@mfs12
Here's the main build repo https://github.com/gloomyandy/RRFBuild/tree/v3.4-dev