<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 8, 2016, at 9:20 PM, David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">At some later date, maybe we’ll get “swift build --run-tests” or “swift tests --no-build” that simply runs the tests<span class="Apple-converted-space"> </span></span><b class="" style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">without</b><span style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""> attempting to do a build. Ok, maybe we will. If it’s a week later, ok. If it’s a month later, ok. If it’s going to be a year away, that becomes a real issue. However, there is no compelling reason to couple this from the start, especially if there is no architectural considerations to worry about.</span></div></blockquote></div><div class=""><br class=""></div><div class="">I think the common case (perhaps it is uncommon for you) is a test-driven implementation loop, where somebody has a failing test, they are working in a text editor or IDE, and they want to know if it the thing they changed caused the tests to pass. This is my workflow when I PR something to Foundation or SwiftPM, and my workflow on other projects.</div><div class=""><br class=""></div><div class="">Certainly that could be accomplished via chaining commands instead (e.g. "swift build && swift test") which better supports your workflow although that is slightly more awkward for the common situation.</div><div class=""><br class=""></div><div class="">But in any case this whole argument feels to me like a bikeshed–we have infinite freedom to support any number of CLI commands, with builds & tests together, separated, in a box, with a fox. This one was elected to support a common workflow, not to the exclusion of all the other things we could do additionally.</div><div class=""><br class=""></div><div class="">But there is language being used on this point (from several people) like:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="font-family: HelveticaNeue;" class="">there is no compelling reason to couple this from the start</span></blockquote><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class=""><span style="font-family: HelveticaNeue;" class="">My biggest concern with this proposal, as it stands, is that it isn't considering what I think are some very important details that will shape the way the build-tool works longer-term.</span></div></blockquote><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">For example, before any meaningful work can be done to support different types of test runners, the work is going to need to done to break the build & run tests coupling. In this way, I think the proposal does a disservice because it’s not laying a good foundation to build on, it’s laying a foundation that we already know needs to be broken up.</blockquote><br class=""></div><div class="">I fail to understand how the election of one (first) command line argument has any of these follow-on consequences at all. We are discussing a CLI frontend, not an architecture diagram.</div><div class=""><br class=""></div><div class="">If someone believes we are in danger of laying a bad foundation then that is an important objection, but to understand it we need an argument of the form</div><div class=""><br class=""></div><div class="">1. "swift build -t"</div><div class="">2. ???</div><div class="">3. Therefore, [specific irreversible harm]</div><div class=""><br class=""></div><div class="">Until that is laid out in a way I can follow, I can't make sense of the objection.</div></body></html>