[libcamera-devel,v2,0/2] libcamera: revert C++17 specific code for public API
mbox series

Message ID 20210126130415.26849-1-jeanmichel.hautbois@ideasonboard.com
Headers show
Series
  • libcamera: revert C++17 specific code for public API
Related show

Message

Jean-Michel Hautbois Jan. 26, 2021, 1:04 p.m. UTC
Some applications may not be compliant with C++17 (Chromium, as an
example). Keep the C++17 features for libcamera internals, and C++14
compliance for public API.

---
Changes in v2:
- keep each revert separate

Jean-Michel Hautbois (2):
  Revert "libcamera: span: Provide and use helper variable templates for
    type traits"
  Revert "libcamera: Use helper variable template for type traits"

 include/libcamera/bound_method.h |  2 +-
 include/libcamera/controls.h     | 24 +++++------
 include/libcamera/object.h       |  2 +-
 include/libcamera/signal.h       |  4 +-
 include/libcamera/span.h         | 70 +++++++++++++++-----------------
 5 files changed, 48 insertions(+), 54 deletions(-)

Comments

Laurent Pinchart Jan. 26, 2021, 9:18 p.m. UTC | #1
Hi Jean-Michel,

Thank you for the patch.

On Tue, Jan 26, 2021 at 02:04:13PM +0100, Jean-Michel Hautbois wrote:
> Some applications may not be compliant with C++17 (Chromium, as an
> example). Keep the C++17 features for libcamera internals, and C++14
> compliance for public API.

This should be captured in the commit message of the two patches, as the
cover letter won't end up in the git history.

The series make sense, the more lightweight our requirements will be in
terms of modern features in the public API, the more applications will
be able to use libcamera. libcamera itself stays C++17, but at this
point of time, sticking to C++14 in the public API isn't a huge hassle.

This is of course a matter of finding a proper balance, I'm sure we will
eventually want to move the public API to C++17 too. Chromium is the
only application I'm aware of that is affected by the lack of C++17
support, and it will eventually get migrated, solving this particular
issue. We will then be able to revert the reverts, if desired.

I've also been wondering if the libcamera integration in Chromium could
be compiled with -std=c++17, with the rest of the browser still compiled
in C++14 mode. It could be useful to get a confirmation from Google on
whether this is possible or not. I've asked and am waiting for feedback,
but this isn't blocking and we can move ahead with this series.

With the commit message updated (which can be done when applying),

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

I'll give others a few days to shime in if desired before pushing this.

> ---
> Changes in v2:
> - keep each revert separate
> 
> Jean-Michel Hautbois (2):
>   Revert "libcamera: span: Provide and use helper variable templates for
>     type traits"
>   Revert "libcamera: Use helper variable template for type traits"
> 
>  include/libcamera/bound_method.h |  2 +-
>  include/libcamera/controls.h     | 24 +++++------
>  include/libcamera/object.h       |  2 +-
>  include/libcamera/signal.h       |  4 +-
>  include/libcamera/span.h         | 70 +++++++++++++++-----------------
>  5 files changed, 48 insertions(+), 54 deletions(-)
Laurent Pinchart Jan. 26, 2021, 9:25 p.m. UTC | #2
On Tue, Jan 26, 2021 at 11:19:06PM +0200, Laurent Pinchart wrote:
> Hi Jean-Michel,
> 
> Thank you for the patch.
> 
> On Tue, Jan 26, 2021 at 02:04:13PM +0100, Jean-Michel Hautbois wrote:
> > Some applications may not be compliant with C++17 (Chromium, as an
> > example). Keep the C++17 features for libcamera internals, and C++14
> > compliance for public API.
> 
> This should be captured in the commit message of the two patches, as the
> cover letter won't end up in the git history.
> 
> The series make sense, the more lightweight our requirements will be in
> terms of modern features in the public API, the more applications will
> be able to use libcamera. libcamera itself stays C++17, but at this
> point of time, sticking to C++14 in the public API isn't a huge hassle.
> 
> This is of course a matter of finding a proper balance, I'm sure we will
> eventually want to move the public API to C++17 too. Chromium is the
> only application I'm aware of that is affected by the lack of C++17
> support, and it will eventually get migrated, solving this particular
> issue. We will then be able to revert the reverts, if desired.
> 
> I've also been wondering if the libcamera integration in Chromium could
> be compiled with -std=c++17, with the rest of the browser still compiled
> in C++14 mode. It could be useful to get a confirmation from Google on
> whether this is possible or not. I've asked and am waiting for feedback,
> but this isn't blocking and we can move ahead with this series.

https://github.com/jhautbois/chromium/blob/master/skia/BUILD.gn#L205

Could something similar be done for libcamera ?

> With the commit message updated (which can be done when applying),
> 
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> I'll give others a few days to shime in if desired before pushing this.
> 
> > ---
> > Changes in v2:
> > - keep each revert separate
> > 
> > Jean-Michel Hautbois (2):
> >   Revert "libcamera: span: Provide and use helper variable templates for
> >     type traits"
> >   Revert "libcamera: Use helper variable template for type traits"
> > 
> >  include/libcamera/bound_method.h |  2 +-
> >  include/libcamera/controls.h     | 24 +++++------
> >  include/libcamera/object.h       |  2 +-
> >  include/libcamera/signal.h       |  4 +-
> >  include/libcamera/span.h         | 70 +++++++++++++++-----------------
> >  5 files changed, 48 insertions(+), 54 deletions(-)
Jean-Michel Hautbois Jan. 27, 2021, 6:46 a.m. UTC | #3
Hi Laurent,

On 26/01/2021 22:25, Laurent Pinchart wrote:
> On Tue, Jan 26, 2021 at 11:19:06PM +0200, Laurent Pinchart wrote:
>> Hi Jean-Michel,
>>
>> Thank you for the patch.
>>
>> On Tue, Jan 26, 2021 at 02:04:13PM +0100, Jean-Michel Hautbois wrote:
>>> Some applications may not be compliant with C++17 (Chromium, as an
>>> example). Keep the C++17 features for libcamera internals, and C++14
>>> compliance for public API.
>>
>> This should be captured in the commit message of the two patches, as the
>> cover letter won't end up in the git history.
>>
>> The series make sense, the more lightweight our requirements will be in
>> terms of modern features in the public API, the more applications will
>> be able to use libcamera. libcamera itself stays C++17, but at this
>> point of time, sticking to C++14 in the public API isn't a huge hassle.
>>
>> This is of course a matter of finding a proper balance, I'm sure we will
>> eventually want to move the public API to C++17 too. Chromium is the
>> only application I'm aware of that is affected by the lack of C++17
>> support, and it will eventually get migrated, solving this particular
>> issue. We will then be able to revert the reverts, if desired.
>>
>> I've also been wondering if the libcamera integration in Chromium could
>> be compiled with -std=c++17, with the rest of the browser still compiled
>> in C++14 mode. It could be useful to get a confirmation from Google on
>> whether this is possible or not. I've asked and am waiting for feedback,
>> but this isn't blocking and we can move ahead with this series.
> 
> https://github.com/jhautbois/chromium/blob/master/skia/BUILD.gn#L205
> 
> Could something similar be done for libcamera ?

Oh, nice catch, this is why I hate BUILD.gn it is not clear where the
options should lie to be correctly applied :-p.
I will try and get back to you !

>> With the commit message updated (which can be done when applying),
>>
>> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>
>> I'll give others a few days to shime in if desired before pushing this.
>>
>>> ---
>>> Changes in v2:
>>> - keep each revert separate
>>>
>>> Jean-Michel Hautbois (2):
>>>   Revert "libcamera: span: Provide and use helper variable templates for
>>>     type traits"
>>>   Revert "libcamera: Use helper variable template for type traits"
>>>
>>>  include/libcamera/bound_method.h |  2 +-
>>>  include/libcamera/controls.h     | 24 +++++------
>>>  include/libcamera/object.h       |  2 +-
>>>  include/libcamera/signal.h       |  4 +-
>>>  include/libcamera/span.h         | 70 +++++++++++++++-----------------
>>>  5 files changed, 48 insertions(+), 54 deletions(-)
>
Jean-Michel Hautbois Jan. 27, 2021, 6:58 a.m. UTC | #4
On 27/01/2021 07:46, Jean-Michel Hautbois wrote:
> Hi Laurent,
> 
> On 26/01/2021 22:25, Laurent Pinchart wrote:
>> On Tue, Jan 26, 2021 at 11:19:06PM +0200, Laurent Pinchart wrote:
>>> Hi Jean-Michel,
>>>
>>> Thank you for the patch.
>>>
>>> On Tue, Jan 26, 2021 at 02:04:13PM +0100, Jean-Michel Hautbois wrote:
>>>> Some applications may not be compliant with C++17 (Chromium, as an
>>>> example). Keep the C++17 features for libcamera internals, and C++14
>>>> compliance for public API.
>>>
>>> This should be captured in the commit message of the two patches, as the
>>> cover letter won't end up in the git history.
>>>
>>> The series make sense, the more lightweight our requirements will be in
>>> terms of modern features in the public API, the more applications will
>>> be able to use libcamera. libcamera itself stays C++17, but at this
>>> point of time, sticking to C++14 in the public API isn't a huge hassle.
>>>
>>> This is of course a matter of finding a proper balance, I'm sure we will
>>> eventually want to move the public API to C++17 too. Chromium is the
>>> only application I'm aware of that is affected by the lack of C++17
>>> support, and it will eventually get migrated, solving this particular
>>> issue. We will then be able to revert the reverts, if desired.
>>>
>>> I've also been wondering if the libcamera integration in Chromium could
>>> be compiled with -std=c++17, with the rest of the browser still compiled
>>> in C++14 mode. It could be useful to get a confirmation from Google on
>>> whether this is possible or not. I've asked and am waiting for feedback,
>>> but this isn't blocking and we can move ahead with this series.
>>
>> https://github.com/jhautbois/chromium/blob/master/skia/BUILD.gn#L205
>>
>> Could something similar be done for libcamera ?
> 
> Oh, nice catch, this is why I hate BUILD.gn it is not clear where the
> options should lie to be correctly applied :-p.
> I will try and get back to you !

I can't make it work, so, if Google replies it can help, as I tried it
in several places in the BUILD.gn file and it has no effect... :-(.

>>> With the commit message updated (which can be done when applying),
>>>
>>> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>>
>>> I'll give others a few days to shime in if desired before pushing this.
>>>
>>>> ---
>>>> Changes in v2:
>>>> - keep each revert separate
>>>>
>>>> Jean-Michel Hautbois (2):
>>>>   Revert "libcamera: span: Provide and use helper variable templates for
>>>>     type traits"
>>>>   Revert "libcamera: Use helper variable template for type traits"
>>>>
>>>>  include/libcamera/bound_method.h |  2 +-
>>>>  include/libcamera/controls.h     | 24 +++++------
>>>>  include/libcamera/object.h       |  2 +-
>>>>  include/libcamera/signal.h       |  4 +-
>>>>  include/libcamera/span.h         | 70 +++++++++++++++-----------------
>>>>  5 files changed, 48 insertions(+), 54 deletions(-)
>>
>