Unclear mechanics of extrascript from library.json

I am trying to create my own (for now local) library with multiplatform/board support. For that I simply export headers where its implementation are done differently per platform/board. I have a subdirectory per case, so it shouldn’t be too difficult to guide the builder/libraryManager towards the correct source dir right?

I dont want to use the platformio.ini file since it is a library (unless its possible to use it for libraries as well > i.e. Have one for the project, and one for each used library. I couldn’t find any info on that)

From what I read, its best to use an extra_script to handle all cases cleanly. But I got a few unknown factors which are hard to find in the documentations:

  1. It seems like the extra script declarations in the library.json file does not support the pre: and post: prefixes? So it can only be run before the actual buildscript? (not that I need the ‘post’ version, but I was wondering)
  2. Assuming there is only a pre-build phase, only the env/Import("env") is valid I assume?
  3. The main src_dir e.s. properties of env are based on the actual project, not the library (eventhough the script is only declared in the library.json file), meaning I should NOT touch those properties/cannot use those properties to alter the library’s source-dir?
  4. The env.GetLibraryBuilders() function always returns an empty array, meaning I cannot easily modify its metadata to pick the correct src-dir based on the build/environment properties? Or is there another trick to this?
  5. I tried adding an action using env.AddPreAction(...). Whether I use buildprog, build, a source-file or a build/output file, it does not seem to fire the action at all, so it might be a ‘project-only’ thing? I was hoping the dependency-graph would be build by than, so I could use the function mentioned in point 4. But maybe I am doing something wrong?
  6. I tried the env.AddBuildMiddleware(...) which does work, so that could be an option, but it doesn’t have my preference as it might add a lot of overhead compared to a src-dir altering.
  7. I read about the env.BuildSources(...) function, but I assume this is meant for the project only and not for library sources? (based on the explanation here

I would love some input for this concept. If I should approuch this problem a different way I would love to know as well.

Thanks in advance!

Well, skipping over the detail questions and straight to what you seem to want: If you have a library which has a src/ dirctory, and under it more folders that need to be conditionally compiled depending on the architecture (say, AVR, STSTM32, …), then really all you need to is to modify the SRC_FILTER of the environment. This is very much akin to the official example.

1 Like

Refer to e.g. gd32-pio-projects/gd32-spl-freertos/lib/FreeRTOS at main · CommunityGD32Cores/gd32-pio-projects · GitHub.

Thanks for your answer. For me this will do for now.

It is an example-driven explanation, which is generally not bad. I would love to see some actual specifications though, as this tool can be verry powerfull IMO, but it’s hard to develop against a ‘black-box’ so to speak.