With some very crude hacking like that can be done, but it isn’t supposed to work that way. You’re right about how it’s supposed to work – SCons needs all the compile options and to-be-compiled sources and include files and linker flags and linker search paths and hook functions for pre/post actions on some specific files etc. and it will then go off and build it with these settings.
It is possible for the builder script to execute an arbitrary command. The ESP-IDF builder script for ESP32 does that e.g. for generating a specific file. Just calls cmake on a data_file_embed_asm.cmake file and gets the output, using env.Execute(). See here.
But if you do that for the whole build process while not adding any files to the build process (env["CPPPATH"] is empty), the SCons build system would complain with “No files to build – error”. So there at least has to be some dummy file. The other ‘gotcha’ is that before calling make nexmon expects you to execute a shell script that fills some environment variables. When make is called through env.Execute(), it probably gets some empty / clean environment that doesn’t have all these needed variables, so care must be taken to generate those and inject them into the environment as well. See SCons doc on how to control the environment variables. (hint: search env = Environment(ENV = os.environ) in the given link, modify env["ENV"]).
As a general note, PlatformIO uses SCons 4.1 in the latest release, and the main docs for that are at Index of /doc/4.1.0/HTML.
The above link is also a pretty good documentation on what variables / keys are within that env object that is getting used for building. Also, I’ve written the custom platform GitHub - maxgerhardt/platform-w60x: PlatformIO platform for WinnerMicro W60X chips. for some WinnerMicro W600 chips and it is a self-contained platform with builder scripts for the Arduino core and the vendor’s SDK, along with the needed packages / declaration for which compiler to use etc. So some things can also be looked up in there.
Also, the general Advanced Scripting documentation is good there, since that’s a page on how to modify the build process, thus also giving insights on how the build process actually works.
Yes partly, but you’re missing an owner and a version, though. See e.g.
Well actually there are two ways for this – in the platform.json you reference package names that are contained in the PlatformIO trusted package registry (see Service End for Bintray, JCenter, GoCenter, and ChartCenter | JFrog with e.g. toolchain-gccarmnoneeabi). So you can’t reference a path on disk there where your toolchain is, you have to pack and publish the package, which invokes the review process by the PlatformIO team. Also, every uploaded package needs to have a package.json metainformation file in it, but you can grab an existing one from e.g. the toolchain-gccarmnoneeabi package as linked in the bintray or in your local installation (cat ~/.platformio/packages/toolchain-gccarmnoneeabi/package.json).
The way that lets you circumvent the PlatformIO registry and work with local files is that you let your platform.json point to some valid,existing package but then in the platformio.ini of the project immediately overwrite it with e.g .platform_packages = toolchain-gccarmnoneeabi@file://<full path here>, see docs and example.