feat(gds): use .oas from user projects when available

[htfab]

No description provided.

[urish]

Thanks!

We should move this step to be part of tt-support-tools (and probably the other preprocessing steps, but that could be a part of a future task). Otherwise, local builds will stop working (or we'll have to add all the steps to BUILDING.md, but our goal is to keep things simple)

[urish]

One advantage of moving this to tt-support-tools is that we will be able to just use the pip installed klayout for this

[htfab]

Yes, it would make sense to include it in copy_macros(). The reason I've put it in the workflow is that it currently interferes with our sky130_density_fix patch. Either we need to do the conversion before applying sky130_density_fix (thus do it in the workflow, as in this PR), or we modify sky130_density_fix to handle .oas as well as .gds. By the way, do we still need the density fix or was it fixed upstream?

[urish]

By the way, do we still need the density fix or was it fixed upstream?

That's a very good question - can you please ask on Slack?

The plan was for the fix to go away after tt10, which is why we haven't included it in tt-support-tools.

Another possible interim solution would be to adjust the density fix script to read/write oas (since it's also based on klayout)

[htfab]

Another possible interim solution would be to adjust the density fix script to read/write oas (since it's also based on klayout)

Looks like the density fix script works with oas files as-is, we just need to call it with an .oas argument.
So I moved the actual conversion to tt-support-tools and this PR is now reduced to an extra call to the density fix for .oas files.

[urish]

We also need to update the submodule, right?

[htfab]

Yes