Moving to a new `Platforms/` directory

Committers
1

After Should we have a `Platforms/` directory in the repo? and the poll held within it, I opened an issue with the steering council to see what they wanted to do.

Their response was:

The SC generally likes the idea of introducing a Platforms directory.
However, we believe that other platforms should also be moved into this new directory.
Our preference is to reach consensus with the other platform maintainers and establish a concrete migration plan together.

And so I’m opening this issue to talk with @steve.dower @nad @freakboy3742 about what a “concrete migration plan” looks like.

13 Likes
2

fwiw I do think this started to be covered above. ex: if PC is easier to move that PCbuild, start there for windows, etc. the pain for integrators is understandable. but it’ll be a onetime cost for them to update something to adapt (even if annoying). my personal recommendation: plan sort of like a deprecation, give a heads up for a release or two, and do it. The directory layout for platform build bits is not a public API. but doing that is still polite when we know of a reason.

2 Likes
3

My plan for WASI is:

  1. Talk with @freakboy3742 about whether we want Platforms/Wasm/... and WASI and Emscripten go there or each platform directly under Platforms/.
  2. Copy the files under Tools/wasm/wasi to their new location
  3. Update Tools/wasm/wasi/__main__.py to run the code from its new location with a warning (I’m fine with a deprecation until 3.20)
  4. Update Tools/wasm/README.md
2 Likes
4

At this point, is there anything other than legacy scripts that is actually shared between WASI and Emscripten (or any reason to believe there will be in future)? The wasm_build.py script is the only real candidate I can see, and I’m not sure that’s even being used by anything in the Emscripten setup.

On that basis, I don’t see any reason to have the intermediate Wasm directory - we might as well treat the two platforms as separate platform folders.

4 Likes
5

Unfortunately, I don’t think a deprecation is really helpful here from the Windows side (thinking primarily of the single set of build scripts we use for releasing all versions). The best we could do is run two copies of the build scripts in parallel for that period, or possibly come up with a suitable set of shims in the new location to allow people to switch early.

I believe the question I asked above was whether we should move the rest of the Windows-specific modules out of PC and into Modules, which would basically make the PC directory redundant (there few remaining files might as well go into the new Platforms\Windows directory, and PC\layout could become Tools\pclayout or Tools\winlayout - again, duplicated for the transition period to allow users to choose when to switch).

2 Likes
6

Just the README, and it’s already split into parts.

It isn’t used by WASI either.

:+1:

Any drawback if they were moved long term?

7

I don’t think so, just that non-Windows contributors will have extra files to ignore. Though we’ll have to do something a bit more clever anyway with PC/config.c and PC/pyconfig.h to avoid conflicting with the generated versions (along with the associated updates to things like setuptools that try and detect them in the source tree).

1 Like