[guardian-dev] The Android Build System Is Broken

[Abel Luck]

So I've discovered a horrible maddening bug with this setup.

ADT occasionally confuses itself when you have projects that are not
located INSIDE the work space (which is exactly what my method below does).

The problem is it barfs on the relative location of library projects,
and when you fix it it does this crazy relative madness.

See attached image.

This is bad because this file (project.properties) is checked into git,
and that crazy relative path is now specific to my computer.

MADNESS!!!!

~abel

Abel Luck:
> One innovation I've happened upon is using a workspaces on a per project
> basis.
> 
> This sounds like a PITA, but it really makes things easier. The cool
> thing is you don't even need to put source repos in the workspace dirs.
> 
> It really simplifies things when you have multiple projects that use the
> same libraries, but maybe different versions or with local patches, etc.
> 
> This is how I've now setup all my projects:
> 
> 
> ~/src/guardian      contains all guardian source repos
>               /PixelKnot
>               /IOCipher
>               /mrapp
>               /Gibberbot
>               .. etc
> 
> ~/src/workspaces    contains empty workspace folders per project
>                /PixelKnot
>                /IOCipher
>                /mrapp
> 
> These workspace dirs are empty! (except for the eclipse .metadata dir)
> 
> ~abel
> 
> 
> Abel Luck:
>> Found this today, though it was posted last July:
>> http://jakewharton.com/the-android-build-system-is-broken/
>>
>> My thoughts derived from Sweat, Blood And Tears:
>>
>> I've spent today and yesterday attempting to clean up and add all
>> Guardian Project projects to our automated build server.
>>
>> Of course I'm also trying to keep things working with Eclipse.
>>
>> Turns out these two goals seem to be in direct conflict.
>>
>> I believe a project should be SIMPLE to setup;
>>           reducing the time-to-coding for new developers is crucial
>>
>> I believe a project should explicitly specify its dependencies in
>>           its repo, so EVERYONE is using the same versions
>>
>> I believe a project should be buildable from the command line with
>>           minimal setup. It should be reducible to one command ideally.
>>
>> These are simple principles of software engineering I've learned leads
>> to elegant code and frictionless processes. The time and effort required
>> to go from 'git clone' to a functioning binary should be minimal
>> (assuming system level things like the SDK, eclipse installed, etc)
>>
>> Eclipse, and Android (in particular ADT) seem to actively defy all these
>> principles.
>>
>> Here are three simple rules I've been trying to implement to create
>> clean project repositories that are clearly specify dependencies and are
>> easy to setup and use by developers:
>>
>> 1. No eclipse files in git
>> 2. All external dependencies defined as submodules in external/
>> 3. .. unless they're jars, those go in libs/
>>
>> A complex project repo sould look like this:
>>
>> /  (git repo)
>> |- app/
>> |----- AndroidManifest.xml
>> |----- src/
>> |----- libs/
>> |----- etc..
>> |- external/
>> | --------- library1/ <--- submodules
>> | --------- library2/ <--- submodules
>> |- README
>>
>> Broken Things and Process:
>>
>> ADT's library project handling is totally broken
>>   example: http://s10.postimg.org/46r1uxe55/shittyadt.png
>>   Both those directories exist and are imported.
>>
>> Whether it works or not, and how it breaks depends upon the order the
>> projects were added to the Eclipse workspace, except when it doesn't in
>> which case it just doesn't work.
>>
>> If you get it working, god forbid you add another 3rd party library at
>> some point in the future.
>>
>> ---
>>
>> Jar dependency conflict resolving sucks
>> ...and by sucks I mean doesn't exist. If two dependencies depend on the
>> same jar, they better be exactly the same (as determined by a sha1sum)
>> or the project won't compile.
>>
>> I realize this problem stems from a a limitation in Dalvik BUT the
>> consequence here is that it is common accepted practice to copy and
>> overwrite jars among all your submodules. WTF?!
>>
>> (why are we shipping jars in the repo at all?)
>>
>> ---
>>
>> Android "support" library should support the developer
>> Imagine if each Android project repo had to ship the SDK as well as its
>> own code. Crazy right? So, why does each project repo need to ship the
>> android support library? Why do I have to write a script like this?
>> https://gist.github.com/abeluck/5374457
>>
>> The support library should be versioned. And, sorry, but when I have 10
>> different jars with "v4" in the name, v4 ceases to mean "version 4"
>>
>> $ find ~/src -name android-support-v4.jar | while read jar; do sha1sum
>> $jar; done | awk '{print $1}' | sort |uniq | wc -l
>> 10
>>
>> *sigh*
>> _______________________________________________
>> Guardian-dev mailing list
>>
>> Post: Guardian-dev at lists.mayfirst.org
>> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
>>
>> To Unsubscribe
>>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/abel%40guardianproject.info
>>
>> You are subscribed as: abel at guardianproject.info
>>
> 
> _______________________________________________
> Guardian-dev mailing list
> 
> Post: Guardian-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev
> 
> To Unsubscribe
>         Send email to:  Guardian-dev-unsubscribe at lists.mayfirst.org
>         Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/abel%40guardianproject.info
> 
> You are subscribed as: abel at guardianproject.info
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: adt-relative-madness.png
Type: image/png
Size: 11091 bytes
Desc: not available
URL: <http://lists.mayfirst.org/pipermail/guardian-dev/attachments/20130426/3a8539df/attachment-0001.png>