Add realclean target to Makefile

[brody4hire]

Quickly delete the generated files, as shown by git status --ignored

[developernotes]

Hi @brodybits

This looks good, however a slight adjustment to the name of the target would be preferred. How do you feel about renaming realclean to distclean, also having distclean invoke clean first? For reference to the naming, here is the specific docs. Thanks!

[brody4hire]

How do you feel about renaming realclean to distclean

Understood and agreed.

also having distclean invoke clean first?

Hmm: I do agree with you in theory, but it is kinda slower. In general, building for Android puts the object code (and libs and executables) in a limited number directories that can easily be wiped away by rm -rf.

In general, I am trying to save myself as much time as I can as I go through the hack-build-test cycle, as I try to reproduce the issue discussed in #169 and #84, that is why I raised this change in the first place. If you feel strongly that distclean should acutally invoke clean, I am happy to do this but at a lower priority (and use my own shell command or alias to blow the generated files away).

A couple more small points:

• If someone deletes all generated files, the user must do make init to generate build.xml again. I think it is smoothest to add an echo statement to the new distclean target to advise the user.
• And there are the objects and other generated files in external, which I did not cover so far. I don't care that much for my own purposes but wonder if we should consider this for others. If yes, I am happy to do this, also at a lower priority.

And finally: I will assume that if I will raise multiple pull requests, which is the case right now, I should raise all pull requests from master for consideration and discussion and NOT have them depend on each other. It will give you more merging tasks, unless you would consider using git cherry-pick instead (which I like happen to like better for handling contributions). If you want me to do this differently please let me know.

[developernotes]

In general, I am trying to save myself as much time as I can as I go through the hack-build-test cycle, as I try to reproduce the issue discussed in #169 and #84, that is why I raised this change in the first place. If you feel strongly that distclean should acutally invoke clean, I am happy to do this but at a lower priority (and use my own shell command or alias to blow the generated files away).

That's fair. Maybe we should rename clean → distclean since it removes the native build artifacts which are more costly time-wise to reproduce. Then your new target would be called clean.

If someone deletes all generated files, the user must do make init to generate build.xml again. I think it is smoothest to add an echo statement to the new distclean target to advise the user.

If clean is now for removal of the build.xml file, maybe that one line should be moved from the init target into a build related target. That way you still only need to run init once. init prepares the OpenSSL source tree for compilation, so minimizing the times you invoke this would be a benefit. Thoughts?

And there are the objects and other generated files in external, which I did not cover so far. I don't care that much for my own purposes but wonder if we should consider this for others. If yes, I am happy to do this, also at a lower priority.

I think this is addressed by the target name swapping between distclean ↔ clean mentioned above, let me know if I missed something.

And finally: I will assume that if I will raise multiple pull requests, which is the case right now, I should raise all pull requests from master for consideration and discussion and NOT have them depend on each other. It will give you more merging tasks, unless you would consider using git cherry-pick instead (which I like happen to like better for handling contributions). If you want me to do this differently please let me know.

We generally always merge pull requests into the prerelease branch, it would be helpful if that is where they originated. I should update the README to reflect that.

[brody4hire]

That's fair. Maybe we should rename clean → distclean since it removes
the native build artifacts which are more costly time-wise to reproduce.
Then your new target would be called clean.

I like this.

If clean is now for removal of the build.xml file, maybe that one line
should be moved from the init target into a build related target. That way
you still only need to run init once. init prepares the OpenSSL source tree
for compilation, so minimizing the times you invoke this would be a
benefit. Thoughts?

👍 Good

I think this is addressed by the target name swapping between distclean ↔
clean mentioned above, let me know if I missed something.

Will check this when I get a chance.

We generally always merge pull requests into the prerelease branch, it
would be helpful if that is where they originated. I should update the
README to reflect that.

Hmm. Looked to me like the prerelease branch is in February 2014, or am I
just seeing things?

And I had thought of a couple additional points:

• I forgot to try this after make release, will do this before submitting
  again
• I had another idea to have release trigger the normal build (if the
  libs are not built), and add a target such as build-release that runs the
  actual commands without checking the dependency/ies. Maybe sometime later.

[brody4hire]

@developernotes I will work on this sometime later and issue a new PR. Right now I am busy cleaning up a new solution to #169, making the tests, and also want to take a look at some other issues such as #161 and #151.

[developernotes]

@brodybits That sounds good. I realized that I mentioned we always integrate pull requests into the prerelease branch, however I should have clarified that is only the case for the core SQLCipher project, not android-database-sqlcipher. Pull requests for android-database-sqlcipher should be based off master.

[brody4hire]

Pull requests for android-database-sqlcipher should be based off master.

That's what I figured.

Sorry to bother you with this but the prerelease branch has really fallen behind. Can we fix this or get rid of the prerelease branch altogether, to avoid the potential for confusion?

[developernotes]

@brodybits I've just removed the prerelease branch in android-database-sqlcipher.

[brody4hire]

@brodybits I've just removed the prerelease branch in android-database-sqlcipher.

👍 thanks, and thanks for your efforts to maintain these projects!

[developernotes]

Certainly, thank you for your interest and involvement in the projects as well!