[PATCH 0/1] vte-native: reduce c++ requirements from c++17 -> c++14

[PATCH 0/1] vte-native: reduce c++ requirements from c++17 -> c++14

[Andreas Müller]

Let the autobuilders decide :)

Andreas Müller (1):
  vte-native: reduce c++ requirements from c++17 -> c++14

 ...uce-gcc-required-support-downto-c-14.patch | 34 ++++++++++++++
 ...001-Revert-parser-glue-Use-std-clamp.patch | 44 +++++++++++++++++++
 ...replace-std-clamp-by-std-min-std-max.patch | 33 ++++++++++++++
 meta/recipes-support/vte/vte_0.56.1.bb        |  7 +++
 4 files changed, 118 insertions(+)
 create mode 100644 meta/recipes-support/vte/vte/0001-Reduce-gcc-required-support-downto-c-14.patch
 create mode 100644 meta/recipes-support/vte/vte/0001-Revert-parser-glue-Use-std-clamp.patch
 create mode 100644 meta/recipes-support/vte/vte/0001-vte.cc-replace-std-clamp-by-std-min-std-max.patch

-- 
2.20.1

[PATCH 1/1] vte-native: reduce c++ requirements from c++17 -> c++14

[Andreas Müller]

This should fix build on ancient hosts

Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
---
 ...uce-gcc-required-support-downto-c-14.patch | 34 ++++++++++++++
 ...001-Revert-parser-glue-Use-std-clamp.patch | 44 +++++++++++++++++++
 ...replace-std-clamp-by-std-min-std-max.patch | 33 ++++++++++++++
 meta/recipes-support/vte/vte_0.56.1.bb        |  7 +++
 4 files changed, 118 insertions(+)
 create mode 100644 meta/recipes-support/vte/vte/0001-Reduce-gcc-required-support-downto-c-14.patch
 create mode 100644 meta/recipes-support/vte/vte/0001-Revert-parser-glue-Use-std-clamp.patch
 create mode 100644 meta/recipes-support/vte/vte/0001-vte.cc-replace-std-clamp-by-std-min-std-max.patch

diff --git a/meta/recipes-support/vte/vte/0001-Reduce-gcc-required-support-downto-c-14.patch b/meta/recipes-support/vte/vte/0001-Reduce-gcc-required-support-downto-c-14.patch
new file mode 100644
index 0000000000..19379b4c9b
--- /dev/null
+++ b/meta/recipes-support/vte/vte/0001-Reduce-gcc-required-support-downto-c-14.patch
@@ -0,0 +1,34 @@
+From 6d33f959f442f1338846f6f80e826f1345951b57 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= <schnitzeltony@gmail.com>
+Date: Sat, 27 Apr 2019 12:52:03 +0200
+Subject: [PATCH] Reduce gcc required support downto c++14
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Native builds require host gcc and they might not support full c++17 but enough
+to build vte-native.
+
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 1c7a753b..698e795d 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -97,7 +97,7 @@ AC_HEADER_STDC
+ AM_PROG_CC_C_O
+ AC_PROG_SED
+ 
+-AX_CXX_COMPILE_STDCXX([17])
++AX_CXX_COMPILE_STDCXX([14])
+ 
+ AC_SYS_LARGEFILE
+ 
+-- 
+2.20.1
+
diff --git a/meta/recipes-support/vte/vte/0001-Revert-parser-glue-Use-std-clamp.patch b/meta/recipes-support/vte/vte/0001-Revert-parser-glue-Use-std-clamp.patch
new file mode 100644
index 0000000000..581996d3c4
--- /dev/null
+++ b/meta/recipes-support/vte/vte/0001-Revert-parser-glue-Use-std-clamp.patch
@@ -0,0 +1,44 @@
+From 9e562ebaf4c01f864cd5791ad759465cb32a9dc5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= <schnitzeltony@gmail.com>
+Date: Sat, 27 Apr 2019 13:03:33 +0200
+Subject: [PATCH] Revert "parser: glue: Use std::clamp"
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+std::clamp requires c++17
+
+Upstream-Status: Inappropriate [configuration]
+
+This reverts commit 1a84c427cd2ea05939b86eb47c21a437d0ce6d79.
+
+Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
+---
+ src/parser-glue.hh | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/parser-glue.hh b/src/parser-glue.hh
+index c12bb784..9c23a0a3 100644
+--- a/src/parser-glue.hh
++++ b/src/parser-glue.hh
+@@ -281,7 +281,7 @@ public:
+                                    int max_v) const noexcept
+         {
+                 auto v = param(idx, default_v);
+-                return std::clamp(v, min_v, max_v);
++                return std::min(std::max(v, min_v), max_v);
+         }
+ 
+         /* param_nonfinal:
+@@ -381,7 +381,7 @@ public:
+                                       int max_v) const noexcept
+         {
+                 int v = __builtin_expect(idx < size(), 1) ? vte_seq_arg_value_final(m_seq->args[idx], default_v) : default_v;
+-                return std::clamp(v, min_v, max_v);
++                return std::min(std::max(v, min_v), max_v);
+         }
+ 
+         /* collect_subparams:
+-- 
+2.20.1
+
diff --git a/meta/recipes-support/vte/vte/0001-vte.cc-replace-std-clamp-by-std-min-std-max.patch b/meta/recipes-support/vte/vte/0001-vte.cc-replace-std-clamp-by-std-min-std-max.patch
new file mode 100644
index 0000000000..ef53458858
--- /dev/null
+++ b/meta/recipes-support/vte/vte/0001-vte.cc-replace-std-clamp-by-std-min-std-max.patch
@@ -0,0 +1,33 @@
+From db3b9cceb55130b0a4b3414be804530c368ececc Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= <schnitzeltony@gmail.com>
+Date: Sat, 27 Apr 2019 13:22:52 +0200
+Subject: [PATCH] vte.cc: replace std:clamp by std:min(std:max(..)..)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+std::clamp requires c++17
+
+Upstream-Status: Inappropriate [configuration]
+
+Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
+---
+ src/vte.cc | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/vte.cc b/src/vte.cc
+index 0aa9a3fc..c9faab49 100644
+--- a/src/vte.cc
++++ b/src/vte.cc
+@@ -5125,7 +5125,7 @@ Terminal::resolve_selection_endpoint(vte::grid::halfcoords const& rowcolhalf, bo
+                 /* Just find the nearest cell boundary within the line, not caring about CJKs, unused
+                  * cells, or wrapping at EOL. The @after parameter is unused in this mode. */
+                 col += half;
+-                col = std::clamp (col, 0L, m_column_count);
++                col = std::min (std::max(col, 0L), m_column_count);
+         } else {
+                 switch (m_selection_type) {
+                 case selection_type_char:
+-- 
+2.20.1
+
diff --git a/meta/recipes-support/vte/vte_0.56.1.bb b/meta/recipes-support/vte/vte_0.56.1.bb
index 3585e9ce57..b261c03191 100644
--- a/meta/recipes-support/vte/vte_0.56.1.bb
+++ b/meta/recipes-support/vte/vte_0.56.1.bb
@@ -19,6 +19,13 @@ SRC_URI += "file://0001-Don-t-enable-stack-protection-by-default.patch \
            file://0001-app.cc-use-old-school-asignment-to-avoid-gcc-4.8-err.patch \
            file://0001-Add-W_EXITCODE-macro-for-non-glibc-systems.patch \
            "
+
+SRC_URI_append_class-native = " \
+    file://0001-Reduce-gcc-required-support-downto-c-14.patch \
+    file://0001-Revert-parser-glue-Use-std-clamp.patch \
+    file://0001-vte.cc-replace-std-clamp-by-std-min-std-max.patch \
+"
+
 SRC_URI[archive.md5sum] = "a8984cd5a101dbff0b0c875d1de3f692"
 SRC_URI[archive.sha256sum] = "02fa8ecc02a9332e47f486795494527b5687b3bd448e73e6b67285f2f326dc7c"
 
-- 
2.20.1

Re: [PATCH 1/1] vte-native: reduce c++ requirements from c++17 -> c++14

[Richard Purdie]

On Mon, 2019-04-29 at 16:07 +0200, Andreas Müller wrote:
> This should fix build on ancient hosts
> 
> Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>

This fixed debian9 but didn't fix centos7 :(

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/150

| checking for a sed that does not truncate output... (cached) sed
| checking whether g++  supports C++14 features by default... no
| checking whether g++  supports C++14 features with -std=gnu++14... no
| checking whether g++  supports C++14 features with -std=gnu++1y... no
| checking whether g++  supports C++14 features with -std=c++14... no
| checking whether g++  supports C++14 features with +std=c++14... no
| checking whether g++  supports C++14 features with -h std=c++14... no
| checking whether g++  supports C++14 features with -std=c++1y... no
| checking whether g++  supports C++14 features with +std=c++1y... no
| checking whether g++  supports C++14 features with -h std=c++1y... no
| configure: error: *** A compiler with support for C++14 language
features is required.

So we may have to look at reverting, or perhaps just adding a vte-
native recipe with an older version of vte?

Cheers,

Richard

Re: [PATCH 1/1] vte-native: reduce c++ requirements from c++17 -> c++14

[Andreas Müller]

On Mon, Apr 29, 2019 at 10:26 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Mon, 2019-04-29 at 16:07 +0200, Andreas Müller wrote:
> > This should fix build on ancient hosts
> >
> > Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
>
> This fixed debian9 but didn't fix centos7 :(
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/150
>
> | checking for a sed that does not truncate output... (cached) sed
> | checking whether g++  supports C++14 features by default... no
> | checking whether g++  supports C++14 features with -std=gnu++14... no
> | checking whether g++  supports C++14 features with -std=gnu++1y... no
> | checking whether g++  supports C++14 features with -std=c++14... no
> | checking whether g++  supports C++14 features with +std=c++14... no
> | checking whether g++  supports C++14 features with -h std=c++14... no
> | checking whether g++  supports C++14 features with -std=c++1y... no
> | checking whether g++  supports C++14 features with +std=c++1y... no
> | checking whether g++  supports C++14 features with -h std=c++1y... no
> | configure: error: *** A compiler with support for C++14 language
> features is required.
>
I expected that - turns nightmarish..

> So we may have to look at reverting, or perhaps just adding a vte-
> native recipe with an older version of vte?
I have no problem with this but is it a good idea to run self test
with a different version as the target one?

What about Ross' suggestion:
> 3. Don't use vte in qemu when building under virgl.  The gtk
> PACKAGECONFIG turns on vte support unconditionally but from glancing
> at the qemu code that isn't a requirement.
Question: If this is accepted and works properly - could we get rid of
vte-native then?

Let's decide some option: I really would like to close this and I have
no problem with either way - gnome-terminal can wait. Gnome stuff just
hobby to me and for test I can add recent vte in my personal
meta-verse.

Andreas

Re: [PATCH 1/1] vte-native: reduce c++ requirements from c++17 -> c++14

[richard.purdie]

On Mon, 2019-04-29 at 22:53 +0200, Andreas Müller wrote:
> On Mon, Apr 29, 2019 at 10:26 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Mon, 2019-04-29 at 16:07 +0200, Andreas Müller wrote:
> > > This should fix build on ancient hosts
> > > 
> > > Signed-off-by: Andreas Müller <schnitzeltony@gmail.com>
> > 
> > This fixed debian9 but didn't fix centos7 :(
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/150
> > 
> > > checking for a sed that does not truncate output... (cached) sed
> > > checking whether g++  supports C++14 features by default... no
> > > checking whether g++  supports C++14 features with
> > > -std=gnu++14... no
> > > checking whether g++  supports C++14 features with
> > > -std=gnu++1y... no
> > > checking whether g++  supports C++14 features with -std=c++14...
> > > no
> > > checking whether g++  supports C++14 features with +std=c++14...
> > > no
> > > checking whether g++  supports C++14 features with -h
> > > std=c++14... no
> > > checking whether g++  supports C++14 features with -std=c++1y...
> > > no
> > > checking whether g++  supports C++14 features with +std=c++1y...
> > > no
> > > checking whether g++  supports C++14 features with -h
> > > std=c++1y... no
> > > configure: error: *** A compiler with support for C++14 language
> > features is required.
> > 
> I expected that - turns nightmarish..
> 
> > So we may have to look at reverting, or perhaps just adding a vte-
> > native recipe with an older version of vte?
> I have no problem with this but is it a good idea to run self test
> with a different version as the target one?

They're totally different uses so whilst I'd normally be cautious, I'm
not sure it matters so much here.

> What about Ross' suggestion:
> > 3. Don't use vte in qemu when building under virgl.  The gtk
> > PACKAGECONFIG turns on vte support unconditionally but from
> > glancing
> > at the qemu code that isn't a requirement.
> Question: If this is accepted and works properly - could we get rid
> of vte-native then?

I've cc'd Alex, I'm sure there was a good reason we did this. I think
it was to avoid having to have a GL enabled X display so I suspect this
isn't an option.

> Let's decide some option: I really would like to close this and I
> have no problem with either way - gnome-terminal can wait. Gnome
> stuff just hobby to me and for test I can add recent vte in my
> personal meta-verse.

Agreed, we need to make a decision, I'm just making sure we have all
the options and then we "just" need to figure out which one to go for.

vte-native of an older version is looking like the best option unless
Alex says I'm mis-remembering...

Cheers,

Richard

Re: [PATCH 1/1] vte-native: reduce c++ requirements from c++17 -> c++14

[Alexander Kanavin]

On Mon, 29 Apr 2019 at 23:22, <richard.purdie@linuxfoundation.org> wrote:
> > Let's decide some option: I really would like to close this and I
> > have no problem with either way - gnome-terminal can wait. Gnome
> > stuff just hobby to me and for test I can add recent vte in my
> > personal meta-verse.
>
> Agreed, we need to make a decision, I'm just making sure we have all
> the options and then we "just" need to figure out which one to go for.
>
> vte-native of an older version is looking like the best option unless
> Alex says I'm mis-remembering...

I checked what --enable-vte actually does in combination with the gtk
UI in qemu, and it makes the serial console tab in the gtk ui behave
like a real gnome-terminal tab (selection, scrolling etc). In the
absence of vte support, the serial console tab is still there and you
can still log in and issue commands, but it is more "dumb" regarding
terminal capabilities. This serial console is an addition to the main
tab where the output from the virtual graphical card goes.

So to conclude: we can split the vte option into its own
PACKAGECONFIG, and leave it disabled for native. I would rather do
this, than make vte and vte-native versions diverge.

Alex

Re: [PATCH 1/1] vte-native: reduce c++ requirements from c++17 -> c++14

[richard.purdie]

On Tue, 2019-04-30 at 12:48 +0200, Alexander Kanavin wrote:
> On Mon, 29 Apr 2019 at 23:22, <richard.purdie@linuxfoundation.org>
> wrote:
> > vte-native of an older version is looking like the best option
> > unless
> > Alex says I'm mis-remembering...
> 
> I checked what --enable-vte actually does in combination with the gtk
> UI in qemu, and it makes the serial console tab in the gtk ui behave
> like a real gnome-terminal tab (selection, scrolling etc). In the
> absence of vte support, the serial console tab is still there and you
> can still log in and issue commands, but it is more "dumb" regarding
> terminal capabilities. This serial console is an addition to the main
> tab where the output from the virtual graphical card goes.
> 
> So to conclude: we can split the vte option into its own
> PACKAGECONFIG, and leave it disabled for native. I would rather do
> this, than make vte and vte-native versions diverge.

Sounds like a plan, can someone send me a patch please! :)

Cheers,

Richard

Re: [PATCH 1/1] vte-native: reduce c++ requirements from c++17 -> c++14

[Andreas Müller]

On Tue, Apr 30, 2019 at 12:53 PM <richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2019-04-30 at 12:48 +0200, Alexander Kanavin wrote:
> > On Mon, 29 Apr 2019 at 23:22, <richard.purdie@linuxfoundation.org>
> > wrote:
> > > vte-native of an older version is looking like the best option
> > > unless
> > > Alex says I'm mis-remembering...
> >
> > I checked what --enable-vte actually does in combination with the gtk
> > UI in qemu, and it makes the serial console tab in the gtk ui behave
> > like a real gnome-terminal tab (selection, scrolling etc). In the
> > absence of vte support, the serial console tab is still there and you
> > can still log in and issue commands, but it is more "dumb" regarding
> > terminal capabilities. This serial console is an addition to the main
> > tab where the output from the virtual graphical card goes.
> >
> > So to conclude: we can split the vte option into its own
> > PACKAGECONFIG, and leave it disabled for native. I would rather do
> > this, than make vte and vte-native versions diverge.
>
> Sounds like a plan, can someone send me a patch please! :)
>
> Cheers,
>
> Richard
>
As the origin of all this I'll try to be the someone

Andreas