[guardian-dev] The Android Build System Is Broken
Abel Luck
abel at guardianproject.info
Fri Apr 26 06:36:56 EDT 2013
Alright. I've believed I've devised an acceptable solution that is sane
(hahahahaha), systematic and repeatable.
-------
Summary
-------
This is for Android projects that use multiple external Android library
projects.
1. One workspace per application
2. Git repo root is your workspace
3. Android library projects go in /external
4. Application itself goes in /app
Example project structure:
~/src (contains your git checkouts)
-----/PixelKnot (the cloned git repo & workspace!)
---------------/app (App source code)
---------------/external (dependency submodules)
------------------------/ActionBarSherlock
-----/StoryMaker
---------------/app
---------------/external
(StoryMaker actually already uses this setup, it gave me the idea.)
>From a fresh git clone, follow this procedure to setup eclipse:
1. Create new workspace in eclipse at the root of the git repo
2. For each library project in external/
Import "Existing Android Code Into Workspace"
3. For the app/ project
Import Existing Projects into Workspace (the non-Android one)
4. Happy dance
-----------
Reasoning
-----------
1. Per-project workspace allows apps to use different versions of the
same libraries
2. Eclipse projects can be easily imported from included .project files
3. ADT requires projects exist in the workspace for relative library
project referencing to work
4. Developers don't have to juggle local changes to the
project.properties file
-----------------------
What this doesn't solve
-----------------------
All the problems with conflicting jars, multiple android-support library
versions still exist, but oh well. At least we can hate Eclipse a little
less.
~abel
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
>>
>
>
>
> _______________________________________________
> 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
>
More information about the Guardian-dev
mailing list