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 <peter.tee...@icloud.com> 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 <
> juergen.sauerm...@t-online.de> 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 <loke...@gmail.com>
> <loke...@gmail.com> 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>
>
>
>
>
