Introduce SwiftBundler library target

[ctreffs]

Motivation

While swift-bundler being an executable is nice and useful, some use-cases require the core functionality of swift-bundler to be available as a library. This allows for example other ArgumentParser based executables to incorporate swift-bundler commands and execute them as part of their CLI.

This PR enables that through introducing a SwiftBundler library target.
All swift-bundler files where moved to that target, except Main.swift which remains the sole file in the swift-bundler executable.

Nothing changes in regards to functionality only the essential types like SwiftBundler where made public.

Library usage

For now we don't expose every type in the public interface, but provide the main entry point to library users.
A library user can then just call

SwiftBundler.main(arguments: ["run", ...])

to invoke swift-bundler as usual.
This ensures no deviation between CLI interface and library functionality while allowing swift-bundler being used inside other CLI code.

CHANGES

• Use official Swift Argument Parser v1.5.0 (makes interface compatible to be imported form different target)
• Move swift-bundler coder to library target SwiftBundler
• Refactor Main.swift to main.swift to support Swift 5.10 main function creation on Windows

[stackotter]

Thanks for doing this 🙏 I replied to your comments and I agree that things should be changed to avoid polluting the global namespace.

I believe that the renaming of SwiftBundler to SwiftBundlerDocumentation will break the update-docsworkflow (which will only run once this is merged so you won't see it in the PR CI results). DocC has been able to generate docs for executable targets for a while now (I think?), so we can probably just move the docs to the CLI target and update the CI action accordingly. The alternative is leaving them inSwiftBundlerDocumentationand updating the action to reflect that, but then the documentation title will beSwiftBundlerDocumentationrather thanSwiftBundlerorswift-bundler`, unless DocC has introduced finer control over that since I set up these docs.

[ctreffs]

I believe that the renaming of SwiftBundler to SwiftBundlerDocumentation will break the update-docsworkflow (which will only run once this is merged so you won't see it in the PR CI results). DocC has been able to generate docs for executable targets for a while now (I think?), so we can probably just move the docs to the CLI target and update the CI action accordingly. The alternative is leaving them inSwiftBundlerDocumentationand updating the action to reflect that, but then the documentation title will beSwiftBundlerDocumentationrather thanSwiftBundlerorswift-bundler`, unless DocC has introduced finer control over that since I set up these docs.

I've recreated what happens on CI locally and as far as I can tell it does not break anything.

I've therefore updated the ./generate_docs.sh script to match whats happening on CI to verify this. Please tell me if this is still as expected.

[stackotter]

Looks good now, just the docs issue which I'll finish my comment on.

[stackotter]

I believe that the renaming of SwiftBundler to SwiftBundlerDocumentation will break the update-docsworkflow (which will only run once this is merged so you won't see it in the PR CI results). DocC has been able to generate docs for executable targets for a while now (I think?), so we can probably just move the docs to the CLI target and update the CI action accordingly. The alternative is leaving them inSwiftBundlerDocumentationand updating the action to reflect that, but then the documentation title will beSwiftBundlerDocumentationrather thanSwiftBundlerorswift-bundler`, unless DocC has introduced finer control over that since I set up these docs.

I've recreated what happens on CI locally and as far as I can tell it does not break anything.

I've therefore updated the ./generate_docs.sh script to match whats happening on CI to verify this. Please tell me if this is still as expected.

The documentation is meant to contain a bunch of usage articles rather than code documentation. Here's what it looks like at the moment; https://swiftbundler.dev/documentation/swiftbundler/

The documentation is currently located at Documentation/SwiftBundler.docc and after your changes would be compiled under the SwiftBundlerDocumentation target. The main issue I see with that (assuming the github workflow gets updated) is that the url would be /documentation/swiftbundlerdocumentation and that the documentation title would probably be SwiftBundlerDocumentation (I seem to remember trying to change the title of a DocC site in the past to no avail).

Might be worth trying to move the docc archive to swift-bundler and then generating docs for that target and seeing how it goes.

[ctreffs]

#65 should be merged as basis for this PR

[stackotter]

Happy to merge this once the Windows CI gets fixed (looks like one of the Signal changes didn't propagate to the #if os(Windows)-gated implementation)

[ctreffs]

The current Windows CI build failure is swift version dependent as it seems. Running this on my local machine everything is fine:

PS C:\Users\ctref\Developer\swift-bundler> swift build --product swift-bundler
Building for debugging...
[1/1] Write auxiliary file C:\Users\ctref\Developer\swift-bundler\.build\x86_64-unknown-windows-msvc\debug\swift-version--4DE95AB4C5047989.txt
Build of product 'swift-bundler' complete! (63.45s)
PS C:\Users\ctref\Developer\swift-bundler> swift --version
Swift version 6.0.2 (swift-6.0.2-RELEASE)
Target: x86_64-unknown-windows-msvc
PS C:\Users\ctref\Developer\swift-bundler>

Have to look into it more in-depth

[stackotter]

The current Windows CI build failure is swift version dependent as it seems. Running this on my local machine everything is fine:

Yeah I've run into that issue before (in SwiftCrossUI's CI), it's such a frustrating bug, no clue why it happens.

[stackotter]

Lgtm! I'll merge this into a new branch, figure out docs stuff, then merge into main.