[mythtv] Java code for android.

Mark Spieth mark at digivation.com.au
Mon May 6 21:55:48 UTC 2019


On 5/7/2019 12:19 AM, Peter Bennett wrote:
>
>
> On 5/6/19 9:54 AM, Mark Spieth wrote:
>> On 5/6/2019 9:59 AM, Gary Buhrmaster wrote:
>>> On Sun, May 5, 2019 at 8:09 PM Peter Bennett <pb.mythtv at gmail.com> 
>>> wrote:
>>>
>>>> I think it is relevant because you want the code to be consistent 
>>>> after
>>>> every commit. If there are dependent changes in java and C++ code they
>>>> need to be committed together.
>>> That is one of the use cases of git submodules
>>> (with the push --recurse-submodules= option),
>>> to insure that the remote repo(s) are consistent,
>>> but I would certainly understand that submodules
>>> is probably a bridge too far.
>>
>> I am beginning to agree with Peter, this should be part of the main 
>> mythtv repo. This is a driver or part thereof.
>>
>> Its not C++ so cant go in the libs dir (or can it?) so another path 
>> should be chosen for the java class path chosen.
>>
>> Questions to be answered:
>>
>> 1. should the manifest go there too?
>>
> That is probably a good idea. I think it would be best to aim for the 
> packaging directory to be as stable as possible and keep the frequent 
> changes all in the mythtv repository. It has already bitten me when I 
> did a pull from mythtv and did a new build only to find it fail 
> because I did not also pull from packaging.
>> 2. all parts of platform source? or only the driver related bit(s)?
>>
> I suggest move the entire directory "android-package-source" to the 
> mythtv repo.
>> 3. how to handle variations in libs?
>>
> Maybe there could be a libs repository. Currently every person who 
> builds could be using different lib versions and results could be 
> unpredictable. A repo with already-compiled libs would also be very 
> nice. The lib build process is somewhat error prone.

That is a good idea. The build area for this would still be in 
packaging, use submodule or plain git clone to import this as part of 
the build for tight versioning somewhere in the android tree in the main 
repo.

Then there is the issue of shadow/out of tree build for android. I would 
like not to pollute the/any in-tree linux build artefacts if at all 
possible.

>> 4. The build system is part build and part packaging. Does this 
>> warrant splitting? Does this affect windows builds (OT maybe windows 
>> can rely on linux subsystem and not care about a specific windows build)
>>
> There is no android build that works in the mythtv repository. This is 
> a difference from all the other platforms, where the code can be built 
> in the mythtv repository and packaged in the packaging repository. It 
> may be possible to change that but it would be a lot of work and there 
> is not much benefit since you cannot run mythtv on android without 
> first packaging it.
Agree, not enough value in doing so.
>> 5. should it be rewritten so that it implements the functioanlity in 
>> C++ calling java where necessary as does the sles driver?
>>
> I considered this but it looked to become very messy and error prone. 
> The way I did it is clean and easy.
I thought as much.

Mark



More information about the mythtv-dev mailing list