Tweak tests and consolidate pins target validation

[thinkyhead]

• Rename tests without -tests suffix.
• Move run_tests to buildroot/bin.
• Update mftest and run_tests with the new paths.
• Replace target test with #include env_validate.h in most pins files.

[p3p]

I disagree completely with this, there are board specific options that require changing the platform build flags, making the env selection more confusing is unnecessary, BOARD_CUSTOM_BUILD_FLAGS works well for these edge cases.

[thinkyhead]

TBF the number of environments now existing already makes the use of the Auto Build Marlin extension practically necessary, and truly there is little guidance from board makers that "LPC1769" would be the right thing to select in PlatformIO for their board named after an animal.

[p3p]

Perhaps but this PR removes a useful feature, adds pointless tests, and will create confusion for people following current guides for the boards.

[thinkyhead]

Someone building for RAMPS in Arduino IDE (or other AVR-oriented build environment) might assume that the BOARD_CUSTOM_BUILD_FLAGS in the pins file will be picked up by that IDE, but it won't.

While the concept might have some utility later, right now it applies only to a single case. The aim of the dependencies scripts was initially to prevent building CPP files that are not used, so PIO builds can be much faster (again) than Arduino IDE builds. It was not itself a dependency required to build Marlin correctly, whereas some other additions have gone that way. I'm disinclined to keep things that only cement more dependency on PIO.

[rhapsodyv]

For context: #19468

BOARD_CUSTOM_BUILD_FLAGS was the reason for us to let our build script include pins file.

But, now with the lasts additions to the build script, we can achieve the same effect translating it to a feature.

For example:

MY_SPECIFIC_BOARD_FEATURE = build_flags=-DMY_BOARD_FOO

then, on pins file, just:

#define MY_SPECIFIC_BOARD_FEATURE

Anyway, none of our features that need extra libs or use scripts or use build_flags will work on arduino ide... so it’s not a issue only with BOARD_CUSTOM_BUILD_FLAGS...

About envs: I prefer having a env for at least a family of boards or chip. One env per board is a nightmare. Worst when we have two or three envs for one board. But too generic envs will mess with the editor intelisence... so we would always need to find a balance between the two.

[thinkyhead]

Sure enough. I have all of that in mind as well.

[rhapsodyv]

About PIO dependency. PIO is basically a package/lib manager on top of SCONS.

If we let out the ability of automatic lib and tooling installation, everything else is plain SCONS.

Recently I migrate a project from IAR to SCONS (yes, just a Sconstruct SCONS script - similar to a makefile, but in python).
Then, moving the project to pio I just needed to create a platformio.ini.

Everything we does with "env" in python is not PlatformIO. It's just SCONS.

The most used building tools are plain makefile (old or simple projects), auto conf (linux masters only), CMake and SCONS.

What I mean is: support scons as a main and unique build tools is not necessarily bad, as most of the projects out there support only one build tool anyway. And our build tool is really powerful.

Maybe we can even integrate scons on arduino ide, I never searched about it.

[p3p]

This feature is currently allowing for skr v1.4 boards to work correctly without users knowing there is a platform config difference, unless that can be preserved I don't think it should be removed yet, adding board specific envs is always a bad idea.

[thinkyhead]

Bringing SCons to other build environments seems like it would be a good idea. Of course, Arduino IDE is packaged to be a standalone application, so it would need to be rebuilt and contain its own Python interpreter.

[thinkyhead]

It is also important to note that our stuff doesn't just depend on SCons, but also on being able to locate a working GCC compiler somewhere in the $PATH to do the initial pre-compile step to pull defines from H and CPP files into a Python dictionary.

[rhapsodyv]

For this specific case of skr, I think it should be translated into a feature.

No one will build lpc on arduino ide.

And making it a feature, will not give a lot of support from users building in the wrong env....

[rhapsodyv]

It is also important to note that our stuff doesn't just depend on SCons, but also on being able to locate a working GCC compiler somewhere in the $PATH to do the initial pre-compile step to pull defines from H and CPP files into a Python dictionary.

Yes, we use some PIO concepts and helpers. But just because we can. It give us some free sugar.

If we try to make it work on arduino ide, we probably need some ifs, but not that much. And for arduino, the tooling is only one and only one folder, isn't?

I will take a look if we can create some sort of arduino ide plugin.

[thinkyhead]

adding board-specific envs is always a bad idea

Users are already forced to dig and learn that their board is "LPC1768" or "STM32F1_blah_blah" at some point, so I don't think it adds any special burden to make them do it once again.

But, if we really do want to make sure users select the right environment, we could have each environment set a -D flag to identify itself, and then each pins file can check that the correct env is selected (only when the identifier is actually set).

[p3p]

With the features .. feature of the platformio.ini we can maintain working SKR v1.4 builds without adding an env with something like the following, LPC will never build with Arduino IDE so I think its acceptable to require platformio for the build process on that platform.

pins_BTT_SKR_V1_4.h

-#ifndef BOARD_CUSTOM_BUILD_FLAGS
-  #define BOARD_CUSTOM_BUILD_FLAGS -DLPC_PINCFG_UART3_P4_28
-#endif
+#define IS_BTT_SKR_V1_4

platformio.ini [common_LPC] section

 custom_marlin.USES_LIQUIDCRYSTAL = arduino-libraries/LiquidCrystal@~1.0.7
 custom_marlin.NEOPIXEL_LED = Adafruit NeoPixel=https://github.com/p3p/Adafruit_NeoPixel/archive/1.5.0.zip
+custom_marlin.IS_BTT_SKR_V1_4 = build_flags=-DLPC_PINCFG_UART3_P4_28

[thisiskeithb]

TBF the number of environments now existing already makes the use of the Auto Build Marlin extension practically necessary

At least with #21068, there's some guidance as soon as the user tries to build with the incorrect environment now.

[thinkyhead]

With due deference to SCons as a newer/better build system than make/cmake, I've dropped the original aim of this PR and just done a bunch of reorganization instead.

[thisiskeithb]

This PR brings back the "Can not remove temporary directory /github/Marlin/.pio/build. Please remove it manually to avoid build issues" build error.

[rhapsodyv]

This PR brings back the "Can not remove temporary directory /github/Marlin/.pio/build. Please remove it manually to avoid build issues" build error.

Missing "env:" here:

platform = ${LPC1768.platform}