Opened 13 years ago
Last modified 6 years ago
#31826 assigned update
android: whitespace cleanup and update to sdk15 + features
Reported by: | ecronin (Eric Cronin) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.0.3 |
Keywords: | Cc: | ||
Port: | android |
Description
First patch normalizes the whitespace which was a mix of spaces and tabs and wasn't consistent with its own modeline.
Second patch does a few things in addition to updating to r15 that just came out. My local version (which is getting harder to re-apply on top of the trunk one because of the whitespace issues) also includes variants for all the google SDKs which means you don't need to open up the permissions and when you 'port uninstall android' you actually uninstall everything instead of leaving a bunch of untracked/unmanaged stuff in ${prefix}. But it also adds 15-20 minutes more work to each update (more this time because google split repository.xml into several files and I had to fire up a proxy to find them), so I understand if you don't want that extra burden.
I would greatly appreciate installing platform-tools and making the symlinks though if you don't take this patch. All I really care about are adb and some of the dex tools, and it's a pain that 'port install android' doesn't give you them.
Attachments (2)
Change History (8)
Changed 13 years ago by ecronin (Eric Cronin)
Attachment: | 0001-android-whitespace-cleanup.patch added |
---|
Changed 13 years ago by ecronin (Eric Cronin)
Attachment: | 0002-android-update-to-r15-internal-changes.patch added |
---|
comment:1 Changed 12 years ago by jmroot (Joshua Root)
comment:2 Changed 12 years ago by ecronin (Eric Cronin)
Portfile is still half tabs half spaces and doesn't match the modeline.
The port still installs the bare minimum amount of the actual Android SDK in a way that's managed by MacPorts, and then the user has to run the java gui installer to install various packages into MacPorts' directory hierarchy, which MacPorts then knows nothing about. There was a mailing list thread not long ago about a user accidentally blowing away some of their VMs because the upgrade often requires you to force activate because of all these untracked files and they instead went in and rm -rf'd them.
The only thing the current port gives a user over them installing the SDK themselves in their homedir the way the Android docs describe is some double-clickable wrappers in /Applications/MacPorts. What it doesn't give is a quick way to get the command line tools to talk to an android device which is all I really care about. If you're doing serious android development you're better off not having your SDK hierarchy under MacPorts' (or any package manager's) control in any way from what I've seen.
I guess I only implied it in the report, but I have no time to maintain something this complex and I don't actually do app development where I use the full SDK and simulators. I just never upgrade the port and ${prefix}/bin/adb still works for what I need.
If the maintainer isn't willing to go all the way to support macports managing everything and without the need to make things under ${prefix} group-writable so packages can be installed there directly I think a better approach would be for the .app wrappers look/ask for a SDK somewhere outside of the MacPorts and that be all that is installed by this port... If they do use the routine to fetch and install packages from Google's manifests subports are a far better idea than all the variants I had in that old patch
comment:3 Changed 12 years ago by ecronin (Eric Cronin)
Keywords: | haspatch removed |
---|
comment:4 Changed 7 years ago by kurthindenburg (Kurt Hindenburg)
Owner: | krischik@… deleted |
---|---|
Status: | new → assigned |
comment:5 Changed 6 years ago by jmroot (Joshua Root)
comment:6 Changed 6 years ago by jmroot (Joshua Root)
Unfortunately I once again have no idea how much of the second patch is applicable to the current version. Since there is no longer a maintainer, please feel free to close this ticket, and/or make whatever changes you think are appropriate, including removing the port if users are better off not using it.
The android port is version 18 now. How much of this is still needed?