Add TSCBasic as a separate product w/o TSCUtility

[MaxDesiatov]

Currently, targets such as SwiftToolsSupport and SwiftToolsSupport-auto can't be built with SwiftPM alone if SQLite is not preinstalled. Also, SwiftToolsSupport depends on TSCUtility, while TSCBasic is enough in a lot of use cases for libraries that rely on TSC.

This PR allows building TSCBasic alone with SwiftPM via new SwiftToolsSupportBasic product, and without having SQLite preinstalled.

The change is purely additive and doesn't touch any of the existing targets or products.

[MaxDesiatov]

@swift-ci please test

[compnerd]

Currently, targets such as SwiftToolsSupport and SwiftToolsSupport-auto can't be built on Windows with SwiftPM alone, they require CMake and sqlite preinstalled.

Can you explain this statement? They should build on Windows just fine with SPM. The SQLite dependency is there on all platforms, that isn't Windows specific.

[MaxDesiatov]

I mean that SQLite is not installed on Windows by default, and SwiftPM doesn't install it automatically for users. An alternative would be to ask users to install SQLite before using a project that depends on TSC, but this doesn't make sense for projects that don't rely on SQLite or any other functionality from TSCUtility and only need TSCBasic.

By "users" I mean users of any other project depending on TSCBasic as a helper package, not the SwiftPM project itself or anything else under swift.org projects umbrella.

[neonichu]

Seems reasonable to me.

[MaxDesiatov]

To clarify, one example of this is Lite, which used to depend on some older version of SwiftPM package, but really only needs TSCBasic and does not need TSCUtility or SQLite functionality. I want to make it buildable with a simple swift build invocation on Windows without any additional steps.

[compnerd]

I mean that SQLite is not installed on Windows by default, and SwiftPM doesn't install it automatically for users. An alternative would be to ask users to install SQLite before using a project that depends on TSC, but this doesn't make sense for projects that don't rely on SQLite or any other functionality from TSCUtility and only need TSCBasic.

Ah, yes, it does have a dependency on SQLite. However, that problem exists on Linux too - Linux doesn't guarantee a pre-installed version of SQLite, and a user must install it. If you intend to suggest that the package management systems on Linux make it easier - vcpkg on Windows does the same.

I don't have a concern with the change itself, though I do feel that the justification as presented is not necessarily something which clearly articulates the issue. The problem that was seen on Windows exists on all the platforms. Would it not make sense to properly describe the situation as the motivation.

[MaxDesiatov]

Fair enough, I thought it was a safe assumption that it comes one way or another on Linux, given how much software relies on it, and I'd assume any installation of Swift would require SQLite to be installed too for SwiftPM itself to work. The problem hadn't come up on Linux so far.

I was also confused by the lack of use of systemLibrary in Package.swift of TSC. I'd expect that to be specified with pkgConfig and providers arguments passed some meaningful values.

I'll clean up the PR description accordingly.

[neonichu]

I was also confused by the lack of use of systemLibrary in Package.swift of TSC. I'd expect that to be specified with pkgConfig and providers arguments passed some meaningful values.

That may be a good separate PR. My guess is that nobody thought of SQLite in that way, because it is basically always already present on macOS and Linux?

[compnerd]

Fair enough, I thought it was a safe assumption that it comes one way or another on Linux, given how much software relies on it, and I'd assume any installation of Swift would require SQLite to be installed too for SwiftPM itself to work. The problem hadn't come up on Linux so far.

IMO no more so than on Windows. I do not believe that installations of Swift in general require SQLite to be installed (though one could trivially construct a counter-example). At least on Windows, we statically link to avoid the distribution issue. I believe that the swift.org nightlies do similar.

I was also confused by the lack of use of systemLibrary in Package.swift of TSC. I'd expect that to be specified with pkgConfig and providers arguments passed some meaningful values.

pkg-config is not portable - it doesn't account for the layout on all platforms. Improvements to the package description to allow for that is an interesting idea, and I think it could be helpful. I know that I've been bitten by the need for the flags before.

I'll clean up the PR description accordingly.

Thanks!

[MaxDesiatov]

Also, while we're at it, do you think that SystemPackageProviderDescription needs to be expanded for Windows in some way? Would we want a new case vcpkg([String]) there?

[neonichu]

Actually, can we call this "TSCBasic" instead? Since this only vends a single target, it makes sense to name the product and target the same.

[compnerd]

Also, while we're at it, do you think that SystemPackageProviderDescription needs to be expanded for Windows in some way? Would we want a new case vcpkg([String]) there?

I suspect that we may want to support nuget before we do vcpkg. nuget is already widely used and well supported in a variety of conditions. I don't know what it would take to properly support that though. I think my personal preference would be to fix SPM testability before we tackle that. But, if you are interested in adding vcpkg and nuget support, I think that the extensions are a positive thing.

[MaxDesiatov]

@swift-ci please test

[MaxDesiatov]

Would it be possible to tag a new release with this change anytime soon?