Re: [Bug-apl] Android features

[Elias Mårtenson]

The GNU license does not allow non-GNU-licensed code to be linked with the binary. There is no question the Android port has to be GNU-licensed as well.

Regards,

Elias

On 17 June 2014 04:28, Peter Teeson <address@hidden> wrote:

Hi Jürgen:

Thanks for responding to my proposal.

Yes I understand and didn't take static into account.

I do like your cleaner and simple proposal.

Where would the source for all these Class XyzInput files be hosted?

Part of the distribution? Or would the end user supply them at build time?

I would hope that they must also be GNU licensed like the rest?

Also would we allow just one Android, one OS X, etc?

And how do you feel about Output? Does it make sense to do the same thing there?

respect……

Peter

On 2014-06-16, at 12:30 PM, Juergen Sauermann <address@hidden> wrote:

Hi Peter,

I see a few problems with your proposal.

Currently class Input has only static functions, so virtual methods can not be used to distinguish
between different implementations of the same function.

Suppose we would fix that by using Input instances. Instead of eg.

#ifdef HAVE_ANDROID

line = Android_Input::get_line();

#else

line = Input::get_android_line();

#endif

We would then have eg.

class Input { ... }
class Android_Input: public Input { ... }
class Normal_Input: public Input { ... }

#ifdef HAVE_ANDROID

  Android_Input a_input;
  Input * input = a_input;

#else

  Normal_Input n_input;
  Input * input = a_input;

#endif

...
line = input->get_line();

IMHO this is only adding complexity without really making things more elegant.

And it does not solve the real problem, which I believe is the following. I assume
that Elias' Java environment has a number of nasty (read: totally incompatible) things that
I cant support in a reasonable (read: portable) way. The two derived classes would still need
to be compiled, but one of them is not portable, which will create a lot of headache for all
non-Android users.

A much cleaner (or at least simpler) proposal, in my eyes, is this:

1. We use two files Input.cc and AndroidInput.cc.
2. Both use the same Input.hh so that all other source files are no affected. Not all functions
    declared in Input.hh need to be implemented, so AndroidInput.cc. can be rather simple.
3. The src/Makefile decides which of the two files shall be compiled in a given environment.

/// Jürgen


On 06/16/2014 04:43 AM, Peter Teeson wrote:

I suggest once again two abstract classes for I/O with virtual methods which can then be inherited from and implemented by the user.
This special case patching of fixes  is not elegant - to me it is smelly coding. 
Sorry if I offend but that's my 2¢.

Peter

On 2014-06-15, at 4:06 PM, Elias Mårtenson <address@hidden> wrote:

Do you think it would be possible to apply this patch that avoids setting up the output streams when compiling for Android? The Android version installs its own that redirects the output to Java streams.

Regards,
Elias
<streams.diff>