[Buildroot] [RFC 1/1] package/pkg-meson.mk: handle possibly non existing compilers

[Buildroot] [RFC 1/1] package/pkg-meson.mk: handle possibly non existing compilers

[Guillaume W. Bres]

To avoid populating the cross-file with non existing compilers,
we tie them to /bin/false

Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
---
I only managed the CXX and FC case,
assuming all the other ones are always there ?
---
 package/pkg-meson.mk | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
index 0632ab21cf..f246a126d1 100644
--- a/package/pkg-meson.mk
+++ b/package/pkg-meson.mk
@@ -68,15 +68,29 @@ else
 PKG_MESON_TARGET_CPU_FAMILY = $(ARCH)
 endif
 
+# To avoid populating the cross-file with non existing compilers,
+# we tie them to /bin/false
+ifeq ($(BR2_TOOLCHAIN_BUILDROOT_CXX),y)
+PKG_MESON_TARGET_CXX = $(TARGET_CXX)
+else
+PKG_MESON_TARGET_CXX = /bin/false
+endif
+
+ifeq ($(BR2_TOOLCHAIN_BUILDROOT_FORTRAN),y)
+PKG_MESON_TARGET_FC = $(TARGET_FC)
+else
+PKG_MESON_TARGET_FC = /bin/false
+endif
+
 # Generates sed patterns for patching the cross-compilation.conf template,
 # since Flags might contain commas the arguments are passed indirectly by
 # variable name (stripped to deal with whitespaces).
 # Arguments are variable containing cflags, cxxflags, ldflags, fcflags
 define PKG_MESON_CROSSCONFIG_SED
         -e "s%@TARGET_CC@%$(TARGET_CC)%g" \
-        -e "s%@TARGET_CXX@%$(TARGET_CXX)%g" \
+        -e "s%@TARGET_CXX@%$(PKG_MESON_TARGET_CXX)%g" \
         -e "s%@TARGET_AR@%$(TARGET_AR)%g" \
-        -e "s%@TARGET_FC@%$(TARGET_FC)%g" \
+        -e "s%@TARGET_FC@%$(PKG_MESON_TARGET_FC)%g" \
         -e "s%@TARGET_STRIP@%$(TARGET_STRIP)%g" \
         -e "s%@TARGET_ARCH@%$(PKG_MESON_TARGET_CPU_FAMILY)%g" \
         -e "s%@TARGET_CPU@%$(GCC_TARGET_CPU)%g" \
-- 
2.20.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [RFC 1/1] package/pkg-meson.mk: handle possibly non existing compilers

[Thomas Petazzoni via buildroot]

On Tue, 16 Aug 2022 11:48:29 +0200
"Guillaume W. Bres" <guillaume.bressaix@gmail.com> wrote:

> To avoid populating the cross-file with non existing compilers,
> we tie them to /bin/false
> 
> Signed-off-by: Guillaume W. Bres <guillaume.bressaix@gmail.com>
> ---
> I only managed the CXX and FC case,
> assuming all the other ones are always there ?
> ---
>  package/pkg-meson.mk | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/package/pkg-meson.mk b/package/pkg-meson.mk
> index 0632ab21cf..f246a126d1 100644
> --- a/package/pkg-meson.mk
> +++ b/package/pkg-meson.mk
> @@ -68,15 +68,29 @@ else
>  PKG_MESON_TARGET_CPU_FAMILY = $(ARCH)
>  endif
>  
> +# To avoid populating the cross-file with non existing compilers,
> +# we tie them to /bin/false
> +ifeq ($(BR2_TOOLCHAIN_BUILDROOT_CXX),y)

This is not correct as this boolean only makes sense when using an
internal toolchain. You should use BR2_INSTALL_LIBSTDCPP (yes, I know
the name is crappy, but it's historical).

> +PKG_MESON_TARGET_CXX = $(TARGET_CXX)
> +else
> +PKG_MESON_TARGET_CXX = /bin/false
> +endif
> +
> +ifeq ($(BR2_TOOLCHAIN_BUILDROOT_FORTRAN),y)

This should be BR2_TOOLCHAIN_HAS_FORTRAN

> +PKG_MESON_TARGET_FC = $(TARGET_FC)
> +else
> +PKG_MESON_TARGET_FC = /bin/false
> +endif

Now, the annoying question: should this be done in pkg-meson.mk, or
should we do it more globally, i.e define TARGET_CXX and TARGET_FC to
correct values only when C++ or Fortran are supported.

Yann, what do you think? Did we ever try to have TARGET_CXX=/bin/false
and TARGET_FC=/bin/false when there is no C++/Fortran support?

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [RFC 1/1] package/pkg-meson.mk: handle possibly non existing compilers

[yann.morin]

Thomas, Guillaume, All,

On 2022-08-16 12:01 +0200, Thomas Petazzoni via buildroot spake thusly:
> On Tue, 16 Aug 2022 11:48:29 +0200
> "Guillaume W. Bres" <guillaume.bressaix@gmail.com> wrote:
> > To avoid populating the cross-file with non existing compilers,
> > we tie them to /bin/false
[--SNIP--]
> Now, the annoying question: should this be done in pkg-meson.mk, or
> should we do it more globally, i.e define TARGET_CXX and TARGET_FC to
> correct values only when C++ or Fortran are supported.
> 
> Yann, what do you think? Did we ever try to have TARGET_CXX=/bin/false
> and TARGET_FC=/bin/false when there is no C++/Fortran support?

I think my non-work identity would also remember commit bd39d11d2eaa
(core/infra: fix build on toolchain without C++), and the mess it
caused, which was fixed by commit 4cd1ab15886a (core: alternate solution
to disable C++).

So, yes, we tried for CXX, and no, we do not want to do it again. For
consistency, we should not try for other languages either, I believe.

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
| +33 534.541.179 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
|      yann.morin (at) orange.com      |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [RFC 1/1] package/pkg-meson.mk: handle possibly non existing compilers

[Thomas Petazzoni via buildroot]

On Tue, 16 Aug 2022 12:12:49 +0200
<yann.morin@orange.com> wrote:

> I think my non-work identity would also remember commit bd39d11d2eaa
> (core/infra: fix build on toolchain without C++), and the mess it
> caused, which was fixed by commit 4cd1ab15886a (core: alternate solution
> to disable C++).

Thanks for the historical details on this one!

> So, yes, we tried for CXX, and no, we do not want to do it again. For
> consistency, we should not try for other languages either, I believe.

So, the Meson-specific solution proposed by Guillaume is relevant?

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [RFC 1/1] package/pkg-meson.mk: handle possibly non existing compilers

[yann.morin]

Thomas, All,

On 2022-08-16 13:53 +0200, Thomas Petazzoni spake thusly:
> On Tue, 16 Aug 2022 12:12:49 +0200
> <yann.morin@orange.com> wrote:
[--SNIP--]
> > So, yes, we tried for CXX, and no, we do not want to do it again. For
> > consistency, we should not try for other languages either, I believe.
> So, the Meson-specific solution proposed by Guillaume is relevant?

Yes, I believe so. Disabling use/detection of tools should be a
per-infra solution: the meson solution (use /bin/false) is incompatible
with the autotools (which break with /bin/false).

As for why using /bin/false in meson, see:
    https://lore.kernel.org/buildroot/20220809162534.GE3168@scaer/

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
| +33 534.541.179 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
|      yann.morin (at) orange.com      |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [RFC 1/1] package/pkg-meson.mk: handle possibly non existing compilers

[Guillaume Bres]

[-- Attachment #1.1: Type: text/plain, Size: 2856 bytes --]

Hello,

>> So, yes, we tried for CXX, and no, we do not want to do it again. For
>> consistency, we should not try for other languages either, I believe.
>So, the Meson-specific solution proposed by Guillaume is relevant

that was my understanding from Yann's clarifications this morning. I
submitted a V1 (non RFC) with your corrections, please disregard the RFC
from now on

Guillaume W. Bres
Software engineer
<guillaume.bressaix@gmail.com>


Le mar. 16 août 2022 à 14:04, <yann.morin@orange.com> a écrit :

> Thomas, All,
>
> On 2022-08-16 13:53 +0200, Thomas Petazzoni spake thusly:
> > On Tue, 16 Aug 2022 12:12:49 +0200
> > <yann.morin@orange.com> wrote:
> [--SNIP--]
> > > So, yes, we tried for CXX, and no, we do not want to do it again. For
> > > consistency, we should not try for other languages either, I believe.
> > So, the Meson-specific solution proposed by Guillaume is relevant?
>
> Yes, I believe so. Disabling use/detection of tools should be a
> per-infra solution: the meson solution (use /bin/false) is incompatible
> with the autotools (which break with /bin/false).
>
> As for why using /bin/false in meson, see:
>     https://lore.kernel.org/buildroot/20220809162534.GE3168@scaer/
>
> Regards,
> Yann E. MORIN.
>
> --
>                                         ____________
> .-----------------.--------------------:       _    :------------------.
> |  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
> | +33 534.541.179 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
> | +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
> |      yann.morin (at) orange.com      |_="    ,--' | / \ HTML MAIL    |
> '--------------------------------------:______/_____:------------------'
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
>

[-- Attachment #1.2: Type: text/html, Size: 4160 bytes --]

[-- Attachment #2: Type: text/plain, Size: 150 bytes --]

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [RFC 1/1] package/pkg-meson.mk: handle possibly non existing compilers

[Arnout Vandecappelle]

On 16/08/2022 12:12, yann.morin@orange.com wrote:
> Thomas, Guillaume, All,
> 
> On 2022-08-16 12:01 +0200, Thomas Petazzoni via buildroot spake thusly:
>> On Tue, 16 Aug 2022 11:48:29 +0200
>> "Guillaume W. Bres" <guillaume.bressaix@gmail.com> wrote:
>>> To avoid populating the cross-file with non existing compilers,
>>> we tie them to /bin/false
> [--SNIP--]
>> Now, the annoying question: should this be done in pkg-meson.mk, or
>> should we do it more globally, i.e define TARGET_CXX and TARGET_FC to
>> correct values only when C++ or Fortran are supported.
>>
>> Yann, what do you think? Did we ever try to have TARGET_CXX=/bin/false
>> and TARGET_FC=/bin/false when there is no C++/Fortran support?
> 
> I think my non-work identity would also remember commit bd39d11d2eaa
> (core/infra: fix build on toolchain without C++), and the mess it
> caused, which was fixed by commit 4cd1ab15886a (core: alternate solution
> to disable C++).
> 
> So, yes, we tried for CXX, and no, we do not want to do it again. For
> consistency, we should not try for other languages either, I believe.

  I think it's the other way round: /bin/false should work fine on sane build 
systems. It's just autotools that is special. And we have a special case for 
that (commit 4cd1ab15886a doesn't go away), so it will keep working.

  Well, assuming that cmake and others will behave correctly with CXX=/bin/false.

  Regards,
  Arnout

> 
> Regards,
> Yann E. MORIN.
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot