Re: [gentoo-dev] [PATCH v3 1/2] meson.eclass: Add meson_add_machine_file and meson_add_native_file helpers
On 1/20/26 9:37 AM, Matt Whitlock wrote: > This would be in the class of errors like std::logic_error from C++: > i.e., the programmer made a mistake in their code. I don't care if > the front falls off in this case since a mistake of this type would > be noticed and corrected by an ebuild author while testing their > ebuild, long before the ebuild ever hits any users. > > The other class of errors, which are like std::runtime_error, arise > from conditions that the programmer has no control over, which are > not due to incorrect code. For that class of errors, yes, I would > insist on the full suite of Portage's prettiness because such errors > are likely to occur on users' systems. > > You will note, I *did* say "at least." That left the door wide open > for more elaborate error handling. I only wanted to make sure that > the thing would noisily blow up rather than quietly generating a > file name lacking a unique identifier. The minimum possible demand > is more likely to be fulfilled. This is NOT good developer UX for ebuild authors to debug and figure out "what the heck is wrong with my machine": >>> Emerging (1 of 1) dev-build/meson-1.9.1::gentoo * meson-1.9.1.tar.gz BLAKE2B SHA512 size ;-) ...[ ok ] * meson-1.9.1.tar.gz.asc BLAKE2B SHA512 size ;-) ...[ ok ] * meson-reference-1.9.1.3 BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking 'meson-1.9.1.tar.gz' to /var/tmp/portage/dev-build/meson-1.9.1/work === Skipping unpack of 'meson-1.9.1.tar.gz.asc' === Skipping unpack of 'meson-reference-1.9.1.3' * Verifying meson-1.9.1.tar.gz ... INFO File /var/tmp/portage/dev-build/meson-1.9.1/distdir/meson-1.9.1.tar. gz verified successfully against the signature in /var/tmp/portage/dev-build/meson-1.9.1/distdir/meson-1.9.1.tar. gz.asc: INFO - status: OpenPGPSignatureStatus.GOOD INFO - valid: True, trusted: True INFO - primary key: BD27B07A5EF45C2ADAF70E0484818A6819AF4A9B INFO - subkey: 60411304C09D36628340EEFFCEB167EFB5722BD6 INFO - timestamp: 2025-09-22 17:52:35 UTC /var/tmp/portage/dev-build/meson-1.9.1/temp/environment: line 3822: notavar: parameter null or not set * The ebuild phase 'unpack' has exited unexpectedly. This type of behavior * is known to be triggered by things such as failed variable assignments * (bug #190128) or bad substitution errors (bug #200313). Normally, before * exiting, bash should have displayed an error message above. If bash did * not produce an error message above, it's possible that the ebuild has * called `exit` when it should have called `die` instead. This behavior * may also be triggered by a corrupt bash binary or a hardware problem * such as memory or cpu malfunction. If the problem is not reproducible or * it appears to occur randomly, then it is likely to be triggered by a * hardware problem. If you suspect a hardware problem then you should try * some basic hardware diagnostics such as memtest. Please do not report * this as a bug unless it is consistently reproducible and you are sure * that your bash binary and hardware are functioning properly. >>> Failed to emerge dev-build/meson-1.9.1, Log file: >>> '/var/log/portage/build/dev-build/meson-1.9.1:20260120-150610.log' * Messages for package dev-build/meson-1.9.1: * Log file: /var/log/portage/build/dev-build/meson-1.9.1:20260120-150610.log * The ebuild phase 'unpack' has exited unexpectedly. This type of behavior * is known to be triggered by things such as failed variable assignments * (bug #190128) or bad substitution errors (bug #200313). Normally, before * exiting, bash should have displayed an error message above. If bash did * not produce an error message above, it's possible that the ebuild has * called `exit` when it should have called `die` instead. This behavior * may also be triggered by a corrupt bash binary or a hardware problem * such as memory or cpu malfunction. If the problem is not reproducible or * it appears to occur randomly, then it is likely to be triggered by a * hardware problem. If you suspect a hardware problem then you should try * some basic hardware diagnostics such as memtest. Please do not report * this as a bug unless it is consistently reproducible and you are sure * that your bash binary and hardware are functioning properly. Furthermore, eclasses are *libraries* so per definition users use them to make stuff, and "abnormal abort" is bad in API boundaries of library code. This is not throwing a catchable user exception here -- this is telling portage that bash exited in a manner "we don't understand, and which *may* be a nonfunctioning binary". bash has std::logic_error and it is called "die". bash has abort() and it is called ":?" among other things. It is not catchable, e.g. it will not run ERR traps. A C++ programmer would be rightly scolded for producing a library that sanity checked its inputs by calling abort() on
Re: [gentoo-dev] [PATCH v3 1/2] meson.eclass: Add meson_add_machine_file and meson_add_native_file helpers
On Tuesday, 20 January 2026 04:20:13 EST, Eli Schwartz wrote: > Sure, I'm just replying regarding my dislike of the idea that someone > who wants an error message would recommend uncleanly aborting. ;) This would be in the class of errors like std::logic_error from C++: i.e., the programmer made a mistake in their code. I don't care if the front falls off in this case since a mistake of this type would be noticed and corrected by an ebuild author while testing their ebuild, long before the ebuild ever hits any users. The other class of errors, which are like std::runtime_error, arise from conditions that the programmer has no control over, which are not due to incorrect code. For that class of errors, yes, I would insist on the full suite of Portage's prettiness because such errors are likely to occur on users' systems. You will note, I *did* say "at least." That left the door wide open for more elaborate error handling. I only wanted to make sure that the thing would noisily blow up rather than quietly generating a file name lacking a unique identifier. The minimum possible demand is more likely to be fulfilled.
Re: [gentoo-dev] [PATCH v3 1/2] meson.eclass: Add meson_add_machine_file and meson_add_native_file helpers
On 1/20/26 4:02 AM, James Le Cuirot wrote:
>> :? is not a proper error reporting mechanism, use
>>
>> [[ -n ${xxx} ]] || die "explanatory message"
>>
>> ${xxx:?} is the same class of error as calling abort() in C and saying
>> "look, it exited nonzero, that's totally safe and clean" meanwhile it is
>> explicitly documented to not run atexit handlers or perform any form of
>> cleanup.
>
> If you omit it, nothing bad will happen, as long as you don't call it more
> than once, which is unlikely. I've already merged the changes, so I'll add
> this on my next batch of fixes.
Sure, I'm just replying regarding my dislike of the idea that someone
who wants an error message would recommend uncleanly aborting. ;)
--
Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v3 1/2] meson.eclass: Add meson_add_machine_file and meson_add_native_file helpers
On Mon, 2026-01-19 at 22:13 -0500, Matt Whitlock wrote:
> On Sunday, 18 January 2026 03:59:56 EST, James Le Cuirot wrote:
> > +meson_add_machine_file() {
> > + local file=${T}/meson.${CHOST}.${ABI}.${1}.ini
> > + cat > "${file}" || die
> > +
> > + if tc-is-cross-compiler || [[ ${ABI} != "${DEFAULT_ABI}" ]]; then
> > + emesonargs+=( --cross-file "${file}" )
> > + else
> > + emesonargs+=( --native-file "${file}" )
> > + fi
> > +}
>
> You are naming the custom native file inappropriately. The custom native
> file should be named "${T}/meson.${CBUILD}.${1}.ini" (${CBUILD} instead of
> ${CHOST}, and no ${ABI}).
It will only use --native-file when CHOST == CBUILD. It doesn't really matter
whether the ABI is included or not, the most important thing is to ensure that
the filename is unique.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v3 1/2] meson.eclass: Add meson_add_machine_file and meson_add_native_file helpers
On Mon, 2026-01-19 at 23:13 -0500, Eli Schwartz wrote:
> On 1/19/26 10:18 PM, Matt Whitlock wrote:
> > On Sunday, 18 January 2026 03:59:56 EST, James Le Cuirot wrote:
> > > +meson_add_machine_file() {
> > > + local file=${T}/meson.${CHOST}.${ABI}.${1}.ini
> >
> > Also, you should at least change that ${1} to ${1:?} so that you raise an
> > error if the function argument is missing or blank.
>
>
> :? is not a proper error reporting mechanism, use
>
> [[ -n ${xxx} ]] || die "explanatory message"
>
> ${xxx:?} is the same class of error as calling abort() in C and saying
> "look, it exited nonzero, that's totally safe and clean" meanwhile it is
> explicitly documented to not run atexit handlers or perform any form of
> cleanup.
If you omit it, nothing bad will happen, as long as you don't call it more
than once, which is unlikely. I've already merged the changes, so I'll add
this on my next batch of fixes.
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH v3 1/2] meson.eclass: Add meson_add_machine_file and meson_add_native_file helpers
On 1/19/26 10:18 PM, Matt Whitlock wrote:
> On Sunday, 18 January 2026 03:59:56 EST, James Le Cuirot wrote:
>> +meson_add_machine_file() {
>> +local file=${T}/meson.${CHOST}.${ABI}.${1}.ini
>
> Also, you should at least change that ${1} to ${1:?} so that you raise an
> error if the function argument is missing or blank.
:? is not a proper error reporting mechanism, use
[[ -n ${xxx} ]] || die "explanatory message"
${xxx:?} is the same class of error as calling abort() in C and saying
"look, it exited nonzero, that's totally safe and clean" meanwhile it is
explicitly documented to not run atexit handlers or perform any form of
cleanup.
--
Eli Schwartz
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH v3 1/2] meson.eclass: Add meson_add_machine_file and meson_add_native_file helpers
On Sunday, 18 January 2026 03:59:56 EST, James Le Cuirot wrote:
> +meson_add_machine_file() {
> + local file=${T}/meson.${CHOST}.${ABI}.${1}.ini
Also, you should at least change that ${1} to ${1:?} so that you raise an error
if the function argument is missing or blank.
Re: [gentoo-dev] [PATCH v3 1/2] meson.eclass: Add meson_add_machine_file and meson_add_native_file helpers
On Sunday, 18 January 2026 03:59:56 EST, James Le Cuirot wrote:
> +meson_add_machine_file() {
> + local file=${T}/meson.${CHOST}.${ABI}.${1}.ini
> + cat > "${file}" || die
> +
> + if tc-is-cross-compiler || [[ ${ABI} != "${DEFAULT_ABI}" ]]; then
> + emesonargs+=( --cross-file "${file}" )
> + else
> + emesonargs+=( --native-file "${file}" )
> + fi
> +}
You are naming the custom native file inappropriately. The custom native file
should be named "${T}/meson.${CBUILD}.${1}.ini" (${CBUILD} instead of ${CHOST},
and no ${ABI}).
