octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Source changes as a result of working to port Octave for Android


From: Corbin Champion
Subject: Re: Source changes as a result of working to port Octave for Android
Date: Mon, 15 Oct 2012 14:58:58 -0700

On Sun, Oct 14, 2012 at 6:06 AM, Jordi Gutiérrez Hermoso <address@hidden> wrote:
On 14 October 2012 02:13, Corbin Champion <address@hidden> wrote:
> All source code modifications necessary, so far, to port Octave to Android
> have been related to Android not being a "normal" distribution of Linux.

I would say the trouble is more that Android isn't a distribution of
GNU, unlike Debian, Slackware, or Red Hat. ;-)

> 1)  Android doesn't have /tmp.  To this end, could we have get_P_tmpdir()
> (found within src/sysdep.cc) use the environment variable TMPDIR if present,
> like what is done by tmpnam (eventually calls, liboctave/tempname.c)?

Windows share this problem. What's done there?

> 2)  Android doesn't have sh found at /bin/sh , instead it is at
> /system/bin/sh (not my fault).  This is a problem in toplev.cc and in
> oct-procbuf.cc.  Can this be changed to being dependent on a ifdef based on
> some variable, such that it defaults to /bin/sh if not already defined?

Sure, what's your specific suggestion? Have you already written this patch?

- Jordi G. H.

1) For Windows, it will check a couple of environment variables and if those aren't found it uses c:\\temp .  For linux it assumes /tmp, doesn't check TEMPDIR or similar before that.  But looking again, it appears to already have a work around.  It has:

#elif defined (P_tmpdir)

  return P_tmpdir;

#else

  return "/tmp";

#endif 

So, I guess I could have set P_tmpdir when doing the build.  So, there is some inconsistency by not checking TMPDIR, but a alternative solution exists.  Do you think it is worth fixing.  I can create a patch for it.

2)  glibc uses variable SHELL_PATH.  It is not consistent with its own use of this variable, but that is what they use when it is not hard coded.  We could do the same here.  I can provide a patch.

I hard coded solutions to both of these, but I can create the patches very soon.

I had to make a couple of changes to .m files as well, but we can get there later.  Those changes I need to review again and make sure I am happy with them. 

Thanks,
Corbin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]