[swift-build-dev] Local tool configuration

[Drew Crawford]

The lack of command line flags was something several of us needed last year, and was the straw that drove a few of us to build our own tooling.  So my vote is obviously that this is a "table stakes" kind of feature.

I have two concerns about the specific proposal.  One is that I share Marcin's view that this deserves a space in the manifest.  We implemented it that way, and having used that system for six months and a dozen packages I would never voluntarily go back to an out-of-band mechanism for compiler flags.  I don't mean to reopen a dead horse here, it's just that manifest inclusion solved all my compiler flags problems, and I experienced zero of the bogeymen that were foretold.  Maybe my usecase is somehow unique.

The other is that we have a long-standing bug open to improve our interoperability with SwiftPM that we hope to get to eventually.  Increasing the complexity of the "package specification" – and in particular introducing new files and entire formats, like JSON, that we don't currently have a reason to parse – significantly raises the complexity of interoperability on our side.  Plain text would be better, and a unified manifest would be better still.

Drew

On October 28, 2016 at 5:11:20 PM, Daniel Dunbar via swift-build-dev (swift-build-dev at swift.org) wrote:

Hi all,

We have a need for local tool (swift build, swift package) configuration data to be able to be present in a repository. Currently, many projects *require* some amount of `-Xcc` or `-Xswiftc` arguments be passed to the tools, and are documenting this in their README files. This is lame... we should support a mechanism by which that data can live inside the project repository.

I *do not* think we should put this data in the manifest -- the manifest should aim to have a good schema for all of the things a package requires. However, we need a stop gap solution to make the package manager easier to use.

I would like to propose that we invent some simple mechanism by which:
1. Local configuration data can live in a checked in location, like `.swiftpm-config`. This would be a simple JSON file with a limited number of options, starting with the -Xcc & -Xswiftc ones.
2. User local configuration data could live in `.swiftpm-config.local`. This would usually be put in .gitignore.
3. The command line tool would use these by default, but with have `--no-config` style options for testing without it. It could also have a `--package-config path/to/config` option to use a different config.
4. We would eventually add `git config` like options under `swift package config`.
5. We would never inherit this data across a package dependency. This is not intended to be a long term solution for how we manage this problem, it is just intended to be something which makes the tool more usable *today*, and thus lets us focus on the bigger problems without ignoring this pain point.
6. As with Git, we would eventually support ~/.swiftpm-config

What do others think?

- Daniel
_______________________________________________
swift-build-dev mailing list
swift-build-dev at swift.org
https://lists.swift.org/mailman/listinfo/swift-build-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20161028/2f69a80d/attachment.html>