[Mesa-dev] [PATCH v2 2/4] st/omx_tizonia: Add --enable-omx-tizonia flag and build files

[Christian König]

Am 14.08.2017 um 11:46 schrieb Julien Isorce:
> Hi Leo,
>
> >It would be better if you can extract the common code between 
> bellagio and tizonia to avoid the duplication.
>
> This is something Gurkirpal and me discussed, like having 
> state_trackers/omx/common, state_trackers/omx/bellagio, 
> state_trackers/omx/tizonia. To anticipate that Gurkirpal sent an email 
> https://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg153562.html 
> <https://www.mail-archive.com/mesa-dev@lists.freedesktop.org/msg153562.html> 
> during the Community Bonding period in May (a few weeks from the date 
> (early May) students are officially accepted to the date (end May) 
> where student actually starts working)
>
> The problem with the directory layout above is that it would look like 
> it will be built together in the same shared library. This is not good 
> because it is suppose to export OMX_ComponentInit for each target. Of 
> course this would still be possible to have 2 shared libs but I 
> believe in state_trackers dir, all sub dir are for one target. Also we 
> were afraid that there would be other limitations so we decided to go 
> for a separate directory.
> And since there were no objections in Gurkirpal's mail above we went 
> this way.
>
> Now if I look into state_trackers/omx_tizonia, in fact the common code 
> with state_trackers/omx_bellagio does not have anything to do with 
> omx. For example "slice_header". Maybe it can be moved to 
> gallium/auxiliary/vl/ like it is done already for vl_rbsp_init. Same 
> for omx_get_screen.

Yeah, completely agree.

>
> So I suggest this 'factorization' to be not a blocker for merging 
> state_trackers/omx_tizonia into usptream. But later on we can move 
> gradually bits from state_trackers/omx_bellagio to gallium/auxiliary. 
> And then make state_trackers/omx_tizonia use it as well.

I would really prefer the other way around, e.g. re-factor first and 
then merge.

> This way you will only bother about maintaining 
> state_trackers/omx_bellagio the time being. This also allows to not 
> slowly get its work lost.
>
> Of course we would have done differently if we knew advance. But as 
> today Gurkirpal won't have enough time to do this factorization/move 
> as the project ends in 1 week. Having all of this merged in upstream 
> is not mandatory to succeed the project but Gurkirpal will need some 
> rest after these 3 months of hard work. And who knows what happens 
> after, whether he will still be around after sometimes or not. And 
> this is entirely up to him.
>
> So again I suggest this factorization/move not to be a blocker for the 
> reasons above. What do you think?

As I wrote above I would rather prefer that this deduplication happens 
before the merge, but that Gurkirpal doesn't have much more time for 
working on that is a good argument against it.

BTW: What is Gurkirpal doing after his GSoC project?

Regards,
Christian.

>
> Thx
> Julien

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170814/fedd1a6c/attachment.html>