[swift-build-dev] Local tool configuration

[Daniel Dunbar]

> On Oct 28, 2016, at 3:35 PM, Marcin Krzyzanowski <marcin.krzyzanowski at gmail.com> wrote:
> 
> This is interesting and I'm happy you rise it here.
> So if I have case where I want something like this:
> 
> $ swift build -c release -Xswiftc -static-stdlib
> 
> then I add something like this to .swiftpm:
> [Xswiftc]
>    -static-stdlib

This is correct.

> 
> and there will be no way to make this parameter public via
> Package.swift for every build when released?

Yes, the intention is not that this be the way for packages which require additional build configuration specify it. That should be done through properly design mechanisms in the manifest.

... but in the meantime, it allows for developers *using* such a package to at least document what is necessary in a project level configuration that can be shared.

Does that clarify things?

 - Daniel

> In general I think it's good idea to have such local file that add
> specific paths etc. though, I feel that we should have this mechanism
> as part of manifest file too (Local override manifest setup).
> 
> btw. maybe Package.swift.local and have it all there?
> 
> 
> --
> Marcin
> 
> 
> On Thu, Oct 27, 2016 at 6:27 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