build tools could use a clean function

[ctava]

wrote a clean function that whacks the Carthage directory and the Cartfile.resolved file.
think its useful to have this function to get your project back to a clean slate, in case you've build dependancies on content/.Frameworks in the Carthage Build and Checkouts folders.

speaking of dependancies on the Carthage directory,
Added $(PROJECT_DIR)/Carthage/Build/Mac. Not sure thats correct/you want/will accept that change.
FRAMEWORK_SEARCH_PATHS = (
"$(inherited)",
"$(PROJECT_DIR)/Carthage/Build/Mac",
);

ideally, the only change to Carthage.xcodeproj/project.pbxproj is the addition of Clean.swift
but then again, had a bunch of challenges building the source from a straight up clone of the repo.

please take a look and let me know if this is a change your interested in and if you have feedback.
certainly willing to fix it up for ya.

-chris

[jspahrsummers]

Thank you for the pull request! ✨

However, I feel like this responsibility is better handled by the version control system—for example, git clean -fxd will delete ignored and untracked files, like those automatically created by Carthage.

It's also problematic because different folks commit different Carthage artifacts. Almost everyone should commit Cartfile.resolved, and some users may want to commit Carthage/Build and Carthage/Checkouts as well, in which case cleaning them would be inappropriate.

Can you maybe clarify how you see this being used, and we can use that to determine whether it's needed on top of the VCS' functionality?

[ctava]

Carthage has been created as a decentralized dependency management tool.
Being a decentralized dependency management tool, for mass use, dependent frameworks will likely need to be committed to each git repository. Users are expected-to and encouraged-to 'drag and drop each framework you want to use from the Carthage/Build folder on disk'. In order to make a build repeatable for typical Xcode IDE use, Carthage/Build folder can't be .gitignored as the dependent frameworks needs to be stored and won't be re-compiled with typical Xcode IDE use (not forcing use of Project.xcworkspace). If you agree that users will want to commit Carthage/Build folder, then git clean -fxd doesn't apply to committed frameworks.

Maven's clean command removes files from the target directory which is a kin to the Carthage/Build directory. Cleaning is making sure that the build tool is compiling each module from scratch. The clean phase, per convention, is meant to make a build reproducible, i.e. it cleans up anything that was created by previous builds. Maven actually left the clean phase in its own lifecycle and i think that was a mistake. mvn clean install is more deterministic than a mvn install without the clean.

Carthage takes the dependency management goodness from Maven but is more like Ant in its decentralized storage of frameworks. Therefore, lets take a look at Ant.
A typical Ant process has the clean target baked in. compile, depends on prepare which depends on clean.

<target name="init"> <property name="sourceDir" value="src"/ > <property name="outputDir" value="classes" /> </target> <target name="clean" depends="init"> <deltree dir="${outputDir}" /> </target> <target name="prepare" depends="clean"> <mkdir dir="${outputDir}" /> </target> <target name="compile" depends="prepare"> <javac srcdir="${sourceDir}" destdir="${outputDir}" /> </target>

Since a goal for Carthage is to be flexible and unintrusive, while I believe clean phase is an essential part of a CRISP build lifecycle, i'm proposing having clean as a separate optional command for the users who commit the Carthage/Build folder.

http://bradapp.blogspot.com/2009/04/crisp-builds.html

http://www.javaworld.com/article/2076208/java-app-dev/automate-your-build-process-using-java-and-ant.html

http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
http://books.sonatype.com/mvnref-book/reference/lifecycle-sect-structure.html#lifecycle-sect-clean
http://maven.apache.org/plugins/maven-clean-plugin/usage.html

p.s.
Yes, its true that cleaning will lead to the same additional commits of re-generated dependent frameworks that would have happened with a build command.

[jspahrsummers]

@ctava Sorry for the delay in getting back to you—I've been on vacation. I'll try to respond in detail very soon!

[jspahrsummers]

After thinking it over, I believe the biggest problem with your suggestion is that cleaning Carthage/Build does not actually result in a clean build the next time around.

All build intermediates are owned by Xcode, and stored in its DerivedData directory. We'd have to delete some of the contents of DerivedData in order to ensure a truly clean build, and I don't believe that it's Carthage's responsibility to do that. It's also easy to imagine that doing so might cause issues for some users.

Furthermore, Cartfile.resolved is not a build artifact, or something that should ever need to be “cleaned.” If there's really something wrong with it, carthage update will create a new copy from scratch anyways.

As both pieces of the proposed clean command aren't really applicable, I don't think we should merge this PR. But I sincerely appreciate you submitting it, and discussing your reasoning at length—thank you! ✨