All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCHv2] add Android support
@ 2011-05-16 23:23 Rafael Gieschke
  2011-05-19  6:18 ` Junio C Hamano
  0 siblings, 1 reply; 13+ messages in thread
From: Rafael Gieschke @ 2011-05-16 23:23 UTC (permalink / raw)
  To: git, gitster


Currently, it is not possible to compile git for Android as the C library (Bionic)
is neither providing getpass nor pw_gecos in struct passwd. Therefore,
NO_GETPASS and NO_PW_GECOS are defined in Makefile. As code for Android can only
be cross-compiled, ANDROID is defined.

If NO_GETPASS is set, getpass is provided in compat/getpass.c from
https://github.com/CyanogenMod/android_external_dropbear/raw/master/netbsd_getpass.c

Signed-off-by: Rafael Gieschke <rafael@gieschke.de>
---
 Makefile          |   28 +++++++++++++
 compat/getpass.c  |  115 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 git-compat-util.h |    4 ++
 ident.c           |    8 +++-
 4 files changed, 154 insertions(+), 1 deletions(-)
 create mode 100644 compat/getpass.c

diff --git a/Makefile b/Makefile
index c4db5af..9b505c8 100644
--- a/Makefile
+++ b/Makefile
@@ -71,6 +71,11 @@ all::
 #
 # Define NO_STRTOK_R if you don't have strtok_r in the C library.
 #
+# Define NO_GETPASS if you don't have getpass in the C library.
+#
+# Define NO_PW_GECOS if you don't have pw_gecos in struct passwd
+# in the C library.
+#
 # Define NO_FNMATCH if you don't have fnmatch in the C library.
 #
 # Define NO_FNMATCH_CASEFOLD if your fnmatch function doesn't have the
@@ -248,6 +253,8 @@ all::
 # dependency rules.
 #
 # Define NATIVE_CRLF if your platform uses CRLF for line endings.
+#
+# Define ANDROID if you are cross-compiling for Android.
 
 GIT-VERSION-FILE: FORCE
 	@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -789,6 +796,20 @@ ifeq ($(uname_S),OSF1)
 	NO_STRTOULL = YesPlease
 	NO_NSEC = YesPlease
 endif
+ifdef ANDROID
+	uname_S := Linux
+	NO_GETPASS = YesPlease
+	NO_PW_GECOS = YesPlease
+	NO_NSEC = YesPlease
+	NO_MKDTEMP = YesPlease
+	NO_PTHREADS = YesPlease
+	NO_PERL = YesPlease
+	NO_OPENSSL = YesPlease
+	NO_CURL = YesPlease
+	NO_EXPAT = YesPlease
+	NO_TCLTK = YesPlease
+	NO_ICONV = YesPlease
+endif
 ifeq ($(uname_S),Linux)
 	NO_STRLCPY = YesPlease
 	NO_MKSTEMPS = YesPlease
@@ -1404,6 +1425,13 @@ ifdef NO_STRTOK_R
 	COMPAT_CFLAGS += -DNO_STRTOK_R
 	COMPAT_OBJS += compat/strtok_r.o
 endif
+ifdef NO_GETPASS
+	COMPAT_CFLAGS += -DNO_GETPASS
+	COMPAT_OBJS += compat/getpass.o
+endif
+ifdef NO_PW_GECOS
+	COMPAT_CFLAGS += -DNO_PW_GECOS
+endif
 ifdef NO_FNMATCH
 	COMPAT_CFLAGS += -Icompat/fnmatch
 	COMPAT_CFLAGS += -DNO_FNMATCH
diff --git a/compat/getpass.c b/compat/getpass.c
new file mode 100644
index 0000000..c62b7e4
--- /dev/null
+++ b/compat/getpass.c
@@ -0,0 +1,115 @@
+/*	$NetBSD: getpass.c,v 1.15 2003/08/07 16:42:50 agc Exp $	*/
+
+/*
+ * Copyright (c) 1988, 1993
+ *	The Regents of the University of California.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#if 0
+#include <sys/cdefs.h>
+#if defined(LIBC_SCCS) && !defined(lint)
+#if 0
+static char sccsid[] = "@(#)getpass.c	8.1 (Berkeley) 6/4/93";
+#else
+__RCSID("$NetBSD: getpass.c,v 1.15 2003/08/07 16:42:50 agc Exp $");
+#endif
+#endif /* LIBC_SCCS and not lint */
+
+#include "namespace.h"
+#endif
+
+#include <assert.h>
+#include <paths.h>
+#include <pwd.h>
+#include <signal.h>
+#include <stdio.h>
+#include <termios.h>
+#include <unistd.h>
+
+#if 0
+#ifdef __weak_alias
+__weak_alias(getpass,_getpass)
+#endif
+#endif
+
+char *
+getpass(prompt)
+	const char *prompt;
+{
+	struct termios term;
+	int ch;
+	char *p;
+	FILE *fp, *outfp;
+	int echo;
+	static char buf[_PASSWORD_LEN + 1];
+	sigset_t oset, nset;
+
+#if 0
+	_DIAGASSERT(prompt != NULL);
+#endif
+
+	/*
+	 * read and write to /dev/tty if possible; else read from
+	 * stdin and write to stderr.
+	 */
+	if ((outfp = fp = fopen(_PATH_TTY, "w+")) == NULL) {
+		outfp = stderr;
+		fp = stdin;
+	}
+
+	/*
+	 * note - blocking signals isn't necessarily the
+	 * right thing, but we leave it for now.
+	 */
+	sigemptyset(&nset);
+	sigaddset(&nset, SIGINT);
+	sigaddset(&nset, SIGTSTP);
+	(void)sigprocmask(SIG_BLOCK, &nset, &oset);
+
+	(void)tcgetattr(fileno(fp), &term);
+	if ((echo = (term.c_lflag & ECHO)) != 0) {
+		term.c_lflag &= ~ECHO;
+		(void)tcsetattr(fileno(fp), TCSAFLUSH /*|TCSASOFT*/, &term);
+	}
+	if (prompt != NULL)
+		(void)fputs(prompt, outfp);
+	rewind(outfp);			/* implied flush */
+	for (p = buf; (ch = getc(fp)) != EOF && ch != '\n';)
+		if (p < buf + _PASSWORD_LEN)
+			*p++ = ch;
+	*p = '\0';
+	(void)write(fileno(outfp), "\n", 1);
+	if (echo) {
+		term.c_lflag |= ECHO;
+		(void)tcsetattr(fileno(fp), TCSAFLUSH/*|TCSASOFT*/, &term);
+	}
+	(void)sigprocmask(SIG_SETMASK, &oset, NULL);
+	if (fp != stdin)
+		(void)fclose(fp);
+	return(buf);
+}
+
diff --git a/git-compat-util.h b/git-compat-util.h
index e0bb81e..c1ba884 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -352,6 +352,10 @@ extern uintmax_t gitstrtoumax(const char *, char **, int);
 extern char *gitstrtok_r(char *s, const char *delim, char **save_ptr);
 #endif
 
+#ifdef NO_GETPASS
+extern char *getpass(const char *prompt);
+#endif
+
 #ifdef NO_HSTRERROR
 #define hstrerror githstrerror
 extern const char *githstrerror(int herror);
diff --git a/ident.c b/ident.c
index 1c4adb0..875d401 100644
--- a/ident.c
+++ b/ident.c
@@ -9,6 +9,12 @@
 
 static char git_default_date[50];
 
+#ifdef NO_PW_GECOS
+#define get_gecos(ignored) "&"
+#else
+#define get_gecos(struct_passwd) (struct_passwd->pw_gecos)
+#endif
+
 static void copy_gecos(const struct passwd *w, char *name, size_t sz)
 {
 	char *src, *dst;
@@ -20,7 +26,7 @@ static void copy_gecos(const struct passwd *w, char *name, size_t sz)
 	 * with commas.  Also & stands for capitalized form of the login name.
 	 */
 
-	for (len = 0, dst = name, src = w->pw_gecos; len < sz; src++) {
+	for (len = 0, dst = name, src = get_gecos(w); len < sz; src++) {
 		int ch = *src;
 		if (ch != '&') {
 			*dst++ = ch;
-- 
1.7.4

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCHv2] add Android support
  2011-05-16 23:23 [PATCHv2] add Android support Rafael Gieschke
@ 2011-05-19  6:18 ` Junio C Hamano
  2011-05-19 11:37   ` Rafael Gieschke
  2011-05-23  8:01   ` Tor Arntsen
  0 siblings, 2 replies; 13+ messages in thread
From: Junio C Hamano @ 2011-05-19  6:18 UTC (permalink / raw)
  To: Rafael Gieschke; +Cc: git

Rafael Gieschke <rafael@gieschke.de> writes:

> Currently, it is not possible to compile git for Android as the C library (Bionic)
> is neither providing getpass nor pw_gecos in struct passwd. Therefore,

Whoa, whoa, wait. That's doing too many things in one patch.

I am still debating myself if this rather huge patch is justifiable, or an
elaborate joke/hoax. Does anybody seriously want to run git on his phone,
tablet or set-top box?

I'd suggest splitting it into three patch series, and justify them
separately.

 (1) Support NO_GECOS_IN_PWENT (Makefile, ident.c);
 (2) Support NO_GETPASS (Makefile, compat/getpass.c, git-compat-util.h); and
 (3) Add uname_S = Android (Makefile).

The first two would become much easier to justify if presented that
way. At least you won't hear from anybody "we don't want that much code to
not to run git on a phone!", as it is not entirely implausible to imagine
environments without support for one or both of these two facilities.

I wonder if you want to emply the rename trick similar to the one used for
hstrerror/githstrerror you can see in the git-compat-util.h header file in
the second step, though.

Thanks.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCHv2] add Android support
  2011-05-19  6:18 ` Junio C Hamano
@ 2011-05-19 11:37   ` Rafael Gieschke
  2011-05-19 12:20     ` Jeff King
  2011-05-19 14:17     ` [PATCHv2] add Android support Junio C Hamano
  2011-05-23  8:01   ` Tor Arntsen
  1 sibling, 2 replies; 13+ messages in thread
From: Rafael Gieschke @ 2011-05-19 11:37 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git


Am 19.05.2011 um 08:18 schrieb Junio C Hamano:

> I am still debating myself if this rather huge patch is justifiable, or an
> elaborate joke/hoax. Does anybody seriously want to run git on his phone,
> tablet or set-top box?
> 

Well, it has been promoted by the wiki since August 7, 2009 (https://git.wiki.kernel.org/index.php?title=GitFaq&diff=prev&oldid=7982). So you have to change either the wiki or the code. And of course, git is great enough that is has to be run everywhere :-). 


> I'd suggest splitting it into three patch series, and justify them
> separately.
> 
> (1) Support NO_GECOS_IN_PWENT (Makefile, ident.c);

Done + renamed to NO_GEOCS_IN_PWENT (was NO_PW_GECOS before) as I really like NO_GECOS_IN_PWENT better. Thanks.

> (2) Support NO_GETPASS (Makefile, compat/getpass.c, git-compat-util.h); and

> I wonder if you want to emply the rename trick similar to the one used for
> hstrerror/githstrerror you can see in the git-compat-util.h header file in
> the second step, though.

I've already thought about this but had concerns that gitgetpass will be very near to git_getpass, which already is in connect.c. But I think that's okay and the rename trick will bring more benefits, such as you will be able to use compat/getpass.c as a replacement for a buggy getpass and to test compat/getpass.c on platforms with predefined getpass, too. So, see new patch.


> (3) Add uname_S = Android (Makefile).
> 
> The first two would become much easier to justify if presented that
> way. At least you won't hear from anybody "we don't want that much code to
> not to run git on a phone!", as it is not entirely implausible to imagine
> environments without support for one or both of these two facilities.


So, you would prefer to leave out ANDROID and use something like "ifeq ($(uname_S),Android)", so you will have to compile using make uname_S=Android? I would be fine with that, too. But I would also be fine with having to specify the build options on the command line or using a config.mak if you want to keep Android out of the Makefile.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCHv2] add Android support
  2011-05-19 11:37   ` Rafael Gieschke
@ 2011-05-19 12:20     ` Jeff King
  2011-05-19 17:30       ` Rafael Gieschke
  2011-05-23  7:04       ` Cross-compiling git (was: [PATCHv2] add Android support) Jakub Narebski
  2011-05-19 14:17     ` [PATCHv2] add Android support Junio C Hamano
  1 sibling, 2 replies; 13+ messages in thread
From: Jeff King @ 2011-05-19 12:20 UTC (permalink / raw)
  To: Rafael Gieschke; +Cc: Junio C Hamano, git

On Thu, May 19, 2011 at 01:37:53PM +0200, Rafael Gieschke wrote:

> > (3) Add uname_S = Android (Makefile).
> > 
> > The first two would become much easier to justify if presented that
> > way. At least you won't hear from anybody "we don't want that much code to
> > not to run git on a phone!", as it is not entirely implausible to imagine
> > environments without support for one or both of these two facilities.
> 
> So, you would prefer to leave out ANDROID and use something like "ifeq
> ($(uname_S),Android)", so you will have to compile using make
> uname_S=Android? I would be fine with that, too. But I would also be
> fine with having to specify the build options on the command line or
> using a config.mak if you want to keep Android out of the Makefile.

The point of uname_S is that it would be found automatically. Sadly,
There is nothing helpful in uname to tell us that we are on android:

  $ uname -a
  Linux localhost 2.6.37.4-cyanogenmod-01332-g7f230e8 #1 PREEMPT Tue Apr
  12 12:54:14 EDT 2011 armv7l GNU/Linux

You could obviously guess from Linux on that architecture, but that
seems flaky to me. You can also figure it out by looking around the
filesystem, but that is not something I'm excited about having the
Makefile do.

So I think we are probably stuck either with the user setting an ANDROID
meta-flag that sets the other flags appropriately, or leaving it up to
the user to provide a sane config.mak.

-Peff

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCHv2] add Android support
  2011-05-19 11:37   ` Rafael Gieschke
  2011-05-19 12:20     ` Jeff King
@ 2011-05-19 14:17     ` Junio C Hamano
  1 sibling, 0 replies; 13+ messages in thread
From: Junio C Hamano @ 2011-05-19 14:17 UTC (permalink / raw)
  To: Rafael Gieschke; +Cc: git

Rafael Gieschke <rafael@gieschke.de> writes:

>> (3) Add uname_S = Android (Makefile).
>> 
>> The first two would become much easier to justify if presented that
>> way. At least you won't hear from anybody "we don't want that much code to
>> not to run git on a phone!", as it is not entirely implausible to imagine
>> environments without support for one or both of these two facilities.
>
> So, you would prefer to leave out ANDROID and use something like "ifeq
> ($(uname_S),Android)", so you will have to compile using make
> uname_S=Android? I would be fine with that, too. But I would also be
> fine with having to specify the build options on the command line or
> using a config.mak if you want to keep Android out of the Makefile.

Ignore differences s/Android/ANDROID/; I just typed differently without
even noticing I was doing so (the same for GECOS-PWENT but if you liked my
name better that is fine by me as well). The point is that I didn't mean
to suggest changing names of symbols you used.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCHv2] add Android support
  2011-05-19 12:20     ` Jeff King
@ 2011-05-19 17:30       ` Rafael Gieschke
  2011-05-19 17:38         ` Jeff King
  2011-05-23  7:04       ` Cross-compiling git (was: [PATCHv2] add Android support) Jakub Narebski
  1 sibling, 1 reply; 13+ messages in thread
From: Rafael Gieschke @ 2011-05-19 17:30 UTC (permalink / raw)
  To: Jeff King; +Cc: Junio C Hamano, git


Am 19.05.2011 um 14:20 schrieb Jeff King:

> The point of uname_S is that it would be found automatically. Sadly,
> There is nothing helpful in uname to tell us that we are on android:
> 

Actually, you can't even call uname as I suspect that you would normally not compile on Android (I don't think that gcc runs on Android) but always cross-compile.


> So I think we are probably stuck either with the user setting an ANDROID
> meta-flag that sets the other flags appropriately, or leaving it up to
> the user to provide a sane config.mak.

Yes, I agree that leaving it up completely to the user to provide a config.mak is a very good option too, especially as build environments might be different and some might want to try building with Perl and libcurl, which would require a config.mak anyhow.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCHv2] add Android support
  2011-05-19 17:30       ` Rafael Gieschke
@ 2011-05-19 17:38         ` Jeff King
  2011-05-19 19:27           ` Rafael Gieschke
  0 siblings, 1 reply; 13+ messages in thread
From: Jeff King @ 2011-05-19 17:38 UTC (permalink / raw)
  To: Rafael Gieschke; +Cc: Junio C Hamano, git

On Thu, May 19, 2011 at 07:30:49PM +0200, Rafael Gieschke wrote:

> > The point of uname_S is that it would be found automatically. Sadly,
> > There is nothing helpful in uname to tell us that we are on android:
> 
> Actually, you can't even call uname as I suspect that you would
> normally not compile on Android (I don't think that gcc runs on
> Android) but always cross-compile.

Good point. Whatever support we provide will need to be user-configured,
then.

> > So I think we are probably stuck either with the user setting an ANDROID
> > meta-flag that sets the other flags appropriately, or leaving it up to
> > the user to provide a sane config.mak.
> 
> Yes, I agree that leaving it up completely to the user to provide a
> config.mak is a very good option too, especially as build environments
> might be different and some might want to try building with Perl and
> libcurl, which would require a config.mak anyhow.

I don't know enough about Android development to know how much
commonality there is between devices and builds. AFAIK, the Android spec
itself only provides the Java-callable API. So for Unix-y stuff like
this, I have no idea what is on stock Android versus Cyanogen for
instance, or even if what is on stock varies from handset to handset.

So yeah, we are probably better not even trying to provide a default set
of flags for Android; we can support specific hacks (like your patches 1
and 2) but leave it up to individual build environments to enable them
as appropriate.

-Peff

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCHv2] add Android support
  2011-05-19 17:38         ` Jeff King
@ 2011-05-19 19:27           ` Rafael Gieschke
  0 siblings, 0 replies; 13+ messages in thread
From: Rafael Gieschke @ 2011-05-19 19:27 UTC (permalink / raw)
  To: Jeff King; +Cc: Git Mailing List, Junio C Hamano


Am 19.05.2011 um 19:38 schrieb Jeff King:

> I don't know enough about Android development to know how much
> commonality there is between devices and builds. AFAIK, the Android spec
> itself only provides the Java-callable API. So for Unix-y stuff like
> this, I have no idea what is on stock Android versus Cyanogen for
> instance, or even if what is on stock varies from handset to handset.

The common shared libraries (which should only be different among different Android versions - e.g. 2.2 vs. 2.1) are provided together with the toolchain in the Android NDK by Google. And as far as I can see, SSH/dropbear is on cyanogenmod as well as on stock Android (at least it is on the emulator). But there might be distributions from vendors without a SSH client.


> So yeah, we are probably better not even trying to provide a default set
> of flags for Android; we can support specific hacks (like your patches 1
> and 2) but leave it up to individual build environments to enable them
> as appropriate.

I agree.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Cross-compiling git (was: [PATCHv2] add Android support)
  2011-05-19 12:20     ` Jeff King
  2011-05-19 17:30       ` Rafael Gieschke
@ 2011-05-23  7:04       ` Jakub Narebski
  2011-05-23 14:30         ` Jeff King
  1 sibling, 1 reply; 13+ messages in thread
From: Jakub Narebski @ 2011-05-23  7:04 UTC (permalink / raw)
  To: Jeff King; +Cc: Rafael Gieschke, Junio C Hamano, git

Jeff King <peff@peff.net> writes:
> On Thu, May 19, 2011 at 01:37:53PM +0200, Rafael Gieschke wrote:
> 
> > > (3) Add uname_S = Android (Makefile).
> > > 
> > > The first two would become much easier to justify if presented that
> > > way. At least you won't hear from anybody "we don't want that much code to
> > > not to run git on a phone!", as it is not entirely implausible to imagine
> > > environments without support for one or both of these two facilities.
> > 
> > So, you would prefer to leave out ANDROID and use something like "ifeq
> > ($(uname_S),Android)", so you will have to compile using make
> > uname_S=Android? I would be fine with that, too. But I would also be
> > fine with having to specify the build options on the command line or
> > using a config.mak if you want to keep Android out of the Makefile.
> 
> The point of uname_S is that it would be found automatically. Sadly,
> There is nothing helpful in uname to tell us that we are on android:
> 
>   $ uname -a
>   Linux localhost 2.6.37.4-cyanogenmod-01332-g7f230e8 #1 PREEMPT Tue Apr
>   12 12:54:14 EDT 2011 armv7l GNU/Linux
> 
> You could obviously guess from Linux on that architecture, but that
> seems flaky to me. You can also figure it out by looking around the
> filesystem, but that is not something I'm excited about having the
> Makefile do.
> 
> So I think we are probably stuck either with the user setting an ANDROID
> meta-flag that sets the other flags appropriately, or leaving it up to
> the user to provide a sane config.mak.

By the way, how well Git supports cross-compiling (which from the
thread is necessity to generate binaries for Android)?  `uname -a`
trick works only when compiling on same machine.

./configure supports --host and --build options, but I don't know if
it pass them down to make somehow.  ANDROID=YesPlease seems wasteful:
what about setting HOST or MACHINE, or even uname_* variables, or just
using Autoconf's `host` (in the form of CPU-VENDOR-OS)?

-- 
Jakub Narebski
Poland
ShadeHawk on #git

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCHv2] add Android support
  2011-05-19  6:18 ` Junio C Hamano
  2011-05-19 11:37   ` Rafael Gieschke
@ 2011-05-23  8:01   ` Tor Arntsen
  1 sibling, 0 replies; 13+ messages in thread
From: Tor Arntsen @ 2011-05-23  8:01 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Rafael Gieschke, git

On Thu, May 19, 2011 at 08:18, Junio C Hamano <gitster@pobox.com> wrote:
> Rafael Gieschke <rafael@gieschke.de> writes:
>
>> Currently, it is not possible to compile git for Android as the C library (Bionic)
>> is neither providing getpass nor pw_gecos in struct passwd. Therefore,
>
> Whoa, whoa, wait. That's doing too many things in one patch.
>
> I am still debating myself if this rather huge patch is justifiable, or an
> elaborate joke/hoax. Does anybody seriously want to run git on his phone,
> tablet or set-top box?

[Just replying to that last general question].

Yes, absolutely. My Nokia N900 is just another Linux box, plugged into
a network it's indistinguishable from the other boxes (laptop, desktop
etc.) on that same network. On the other hand this particular phone
needs no effort to get Git running as it's basically a standard Debian
box with glibc. (And I do build some of the same apps on the phone as
on the desktop or laptop.) For Android it seems to need more work, but
I can easily imagine how Android developers would like to have Git on
their devices.  Sometimes when I'm on mission I don't have room for
the laptop, I only use my phone as the only computer. I'm sure others
do too.

-Tor

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Cross-compiling git (was: [PATCHv2] add Android support)
  2011-05-23  7:04       ` Cross-compiling git (was: [PATCHv2] add Android support) Jakub Narebski
@ 2011-05-23 14:30         ` Jeff King
  2011-05-25 14:20           ` Jakub Narebski
  0 siblings, 1 reply; 13+ messages in thread
From: Jeff King @ 2011-05-23 14:30 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: Rafael Gieschke, Junio C Hamano, git

On Mon, May 23, 2011 at 12:04:44AM -0700, Jakub Narebski wrote:

> > So I think we are probably stuck either with the user setting an ANDROID
> > meta-flag that sets the other flags appropriately, or leaving it up to
> > the user to provide a sane config.mak.
> 
> By the way, how well Git supports cross-compiling (which from the
> thread is necessity to generate binaries for Android)?  `uname -a`
> trick works only when compiling on same machine.

It should work fine if you set the make variables appropriately for the
target platform. But I've never tried it. Didn't msysgit people
cross-compile for a while (or maybe still do)?

> ./configure supports --host and --build options, but I don't know if
> it pass them down to make somehow.  ANDROID=YesPlease seems wasteful:
> what about setting HOST or MACHINE, or even uname_* variables, or just
> using Autoconf's `host` (in the form of CPU-VENDOR-OS)?

I know very little about autoconf internals, but what would
CPU-VENDOR-OS look like? Your CPU is probably some arm variant, though
it will vary from device to device. Your kernel is Linux. The special
steps in this case are about some weird userspace issues. So the
equivalent would be more like finding a Linux distro that ships a crappy
libc.  I guess that is what the "vendor" slot is for?

But even if you somehow tell autoconf or the Makefile "yes, this is
android", you are still going to need to manually specify the set of
knobs that should be tweaked in that case. Whether you call it
"ANDROID=YesPlease" or some other form.

-Peff

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Cross-compiling git (was: [PATCHv2] add Android support)
  2011-05-23 14:30         ` Jeff King
@ 2011-05-25 14:20           ` Jakub Narebski
  2011-05-25 15:06             ` Jeff King
  0 siblings, 1 reply; 13+ messages in thread
From: Jakub Narebski @ 2011-05-25 14:20 UTC (permalink / raw)
  To: Jeff King; +Cc: Rafael Gieschke, Junio C Hamano, git

On Mon, 23 May 2011, Jeff King wrote:
> On Mon, May 23, 2011 at 12:04:44AM -0700, Jakub Narebski wrote:
> 
> > > So I think we are probably stuck either with the user setting an ANDROID
> > > meta-flag that sets the other flags appropriately, or leaving it up to
> > > the user to provide a sane config.mak.
> > 
> > By the way, how well Git supports cross-compiling (which from the
> > thread is necessity to generate binaries for Android)?  `uname -a`
> > trick works only when compiling on same machine.
> 
> It should work fine if you set the make variables appropriately for the
> target platform. But I've never tried it. Didn't msysgit people
> cross-compile for a while (or maybe still do)?

Well, the vague sketch of an idea is for Makefile to set uname_*
variables depending on the contents of `host` / `HOST` build variable,
so that detection is based on the target OS.

> > ./configure supports --host and --build options, but I don't know if
> > it pass them down to make somehow.  ANDROID=YesPlease seems wasteful:
> > what about setting HOST or MACHINE, or even uname_* variables, or just
> > using Autoconf's `host` (in the form of CPU-VENDOR-OS)?
> 
> I know very little about autoconf internals, but what would
> CPU-VENDOR-OS look like? Your CPU is probably some arm variant, though
> it will vary from device to device. Your kernel is Linux. The special
> steps in this case are about some weird userspace issues. So the
> equivalent would be more like finding a Linux distro that ships a crappy
> libc.  I guess that is what the "vendor" slot is for?

Well, http://www.gmplib.org/list-archives/gmp-bugs/2011-January/002156.html
says that it is

  $ ./configure --host=arm-linux-androideabi

(though I am not sure if it shouldn't be arm-androideabi-linux instead).
 
> But even if you somehow tell autoconf or the Makefile "yes, this is
> android", you are still going to need to manually specify the set of
> knobs that should be tweaked in that case.

See first paragraph of my reply.

> Whether you call it "ANDROID=YesPlease" or some other form.

I think it is better to solve more generic issue of cross-compiling
Git rather than solving narrow issue of cross-compiling Git on Android.

Of course we still need the part that sets variables appropriately
when we are compiling for Android (whether natively, or cross-compiling).
-- 
Jakub Narebski
Poland

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Cross-compiling git (was: [PATCHv2] add Android support)
  2011-05-25 14:20           ` Jakub Narebski
@ 2011-05-25 15:06             ` Jeff King
  0 siblings, 0 replies; 13+ messages in thread
From: Jeff King @ 2011-05-25 15:06 UTC (permalink / raw)
  To: Jakub Narebski; +Cc: Rafael Gieschke, Junio C Hamano, git

On Wed, May 25, 2011 at 04:20:00PM +0200, Jakub Narebski wrote:

> Well, the vague sketch of an idea is for Makefile to set uname_*
> variables depending on the contents of `host` / `HOST` build variable,
> so that detection is based on the target OS.

Right. But my point is that there is no uname_* variable that
corresponds to Android (at least from me running "uname" on the one
Android device I have access to).  You need a new variable.

> > Whether you call it "ANDROID=YesPlease" or some other form.
> 
> I think it is better to solve more generic issue of cross-compiling
> Git rather than solving narrow issue of cross-compiling Git on Android.

Sure. But I think there are two orthogonal problems:

  1. How to specify alternate platform defaults when cross-compiling.

  2. When we are compiling for an Android platform, which knobs should
     be tweaked by default, and whether there should be a convenience
     "tweak these Android knobs" switch.

The name of the switch in (2) might be related to how (1) is
implemented, but it doesn't have to be.

Anyway, this is all getting a bit too theoretical to be productive.  I'm
not actually cross-compiling, so I don't really know how well or poorly
our current Makefile handles it, let alone the autoconf support on top
of our Makefile. So without patches to discuss, I think we're just going
in circles.

The original poster just wanted knobs for (2). Having (1) would be neat,
but I don't see any reason to hold up (2) if nobody is actually working
on (1).

-Peff

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2011-05-25 15:07 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-16 23:23 [PATCHv2] add Android support Rafael Gieschke
2011-05-19  6:18 ` Junio C Hamano
2011-05-19 11:37   ` Rafael Gieschke
2011-05-19 12:20     ` Jeff King
2011-05-19 17:30       ` Rafael Gieschke
2011-05-19 17:38         ` Jeff King
2011-05-19 19:27           ` Rafael Gieschke
2011-05-23  7:04       ` Cross-compiling git (was: [PATCHv2] add Android support) Jakub Narebski
2011-05-23 14:30         ` Jeff King
2011-05-25 14:20           ` Jakub Narebski
2011-05-25 15:06             ` Jeff King
2011-05-19 14:17     ` [PATCHv2] add Android support Junio C Hamano
2011-05-23  8:01   ` Tor Arntsen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.