Despite the great interoperability with C on a library level, interoperability on the building level has been pretty cumbersome until this point. In particular with configuration-based build systems (i.e. where tiny test programs are run to find out the platform specifics), such as Autoconf, integrating a C library into an SPM package is always an adventure.
I wonder whether this (i.e., calling ./configure on a source tree and gathering the available target files before handing over to SPM) is now possible in Swift 5.6.
I think that this is definitely possible to achieve with SE-0303. However, I’m assuming that tools such as autoconf need access to a lot of system files to check for compatibility and such, which probably wouldn’t play nice with the sandbox. Meaning that your package, and any consumers of the package would need to be built with the --disable-sandbox flag.
Maybe it would be good for the extensible build tools API to be extended (nice) with a way for plugins to request user permission to escape the sandbox. That way the user does still have control over what gets to run, but doesn’t have to provide the --disable-sandbox flag all the time.
An alternative could be to allow a way for plugins to request read only access to certain directories outside of the package root. That would be a much better solution as long as it’s possible to pre compute which directories autoconf would want access to.
Another issue is that currently, extensible build tools can include prebuilt binaries but iirc they only support Mac, which is pretty restrictive. This is definitely an issue unless autoconf can be easily built as a SwiftPM target.
This is definitely a restriction I want us to lift, but it requires coordination amongst the SSWG and the Swift Core Team to understand exactly how it is we want to structure the support.
I've spoken about the concrete problem elsewhere on the forum ([PITCH] Support for binary dependencies - #2 by lukasa and linked topics). This is a very solvable problem, but we do have to do some work to specify what this means and produce tooling that is capable of solving the issue.