<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">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.</div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Drew</div> <div id="bloop_sign_1477703472532773120" class="bloop_sign"></div> <br><p class="airmail_on">On October 28, 2016 at 5:11:20 PM, Daniel Dunbar via swift-build-dev (<a href="mailto:swift-build-dev@swift.org">swift-build-dev@swift.org</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>Hi all,<br><br>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.<br><br>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.<br><br>I would like to propose that we invent some simple mechanism by which:<br>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.<br>2. User local configuration data could live in `.swiftpm-config.local`. This would usually be put in .gitignore.<br>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.<br>4. We would eventually add `git config` like options under `swift package config`.<br>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.<br>6. As with Git, we would eventually support ~/.swiftpm-config<br><br>What do others think?<br><br> - Daniel<br>_______________________________________________<br>swift-build-dev mailing list<br>swift-build-dev@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-build-dev<br></div></div></span></blockquote></body></html>