From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "QEMU Developers" <qemu-devel@nongnu.org>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [PULL 06/10] configure: don't enable ppc64abi32-linux-user by default
Date: Fri, 11 Sep 2020 09:05:03 +0100 [thread overview]
Message-ID: <87wo10oi1c.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA9E6sGNGn6aYy8DxCVZDYeot9EjRvKLEQ2CzAxUkGyBzg@mail.gmail.com>
Peter Maydell <peter.maydell@linaro.org> writes:
> On Thu, 10 Sep 2020 at 14:15, Alex Bennée <alex.bennee@linaro.org> wrote:
>>
>> The user can still enable this explicitly but they will get a warning
>> at the end of configure for their troubles. This also drops any builds
>> of ppc64abi32 from our CI tests.
>>
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> Message-Id: <20200909112742.25730-7-alex.bennee@linaro.org>
>
> I know this is in a pullreq at this point, but I just got round
> to looking at it, and it has some odd logic in it so I figured
> I'd give my review comments anyway.
>
>> +if test -z "$target_list_exclude" -a -z "$target_list"; then
>> + # if the user doesn't specify anything lets skip deprecating stuff
>> + target_list_exclude=ppc64abi32-linux-user
>
> Doesn't this have the slightly curious logic
> that if we have more than one deprecated target then
> configure with --target-list-exclude=something-else
> will actually build more targets than configure without that
> exclude option (because it will exclude the something-else
> but stop excluding the deprecated targets)? I would have
> expected the deprecated targets to be not compiled unless
> the user explicitly enabled them. I think that would be
> something more like
>
> deprecated_targets_list=ppc64abi32-linux-user
> if test -z "$target_list"; then
> target_list_exclude="$target_list_exclude,$deprecated_targets_list"
> fi
>
> I suppose we would ideally like an "enable all including
> the deprecated stuff", and that gets messy because there's
> no way to do it except listing everything explicitly I think...
Yeah - we could make it smoother although I think the only real users of
--target-list-exclude are the CI systems and they all explicitly exclude
ppc64abi32 when they do it.
Do you want me to re-spin with those changes?
>
>> +fi
>> +
>> +exclude_list=$(echo "$target_list_exclude" | sed -e 's/,/ /g')
>> +for config in $mak_wilds; do
>> + target="$(basename "$config" .mak)"
>> + exclude="no"
>> + for excl in $exclude_list; do
>> + if test "$excl" = "$target"; then
>> + exclude="yes"
>> + break;
>> fi
>> done
>> -fi
>> + if test "$exclude" = "no"; then
>> + default_target_list="${default_target_list} $target"
>> + fi
>> +done
>>
>> # Enumerate public trace backends for --help output
>> trace_backend_list=$(echo $(grep -le '^PUBLIC = True$' "$source_path"/scripts/tracetool/backend/*.py | sed -e 's/^.*\/\(.*\)\.py$/\1/'))
>> @@ -7557,7 +7558,7 @@ TARGET_SYSTBL=""
>> case "$target_name" in
>> i386)
>> mttcg="yes"
>> - gdb_xml_files="i386-32bit.xml"
>> + gdb_xml_files="i386-32bit.xml"
>> TARGET_SYSTBL_ABI=i386
>> TARGET_SYSTBL=syscall_32.tbl
>> ;;
>
> (unrelated change ;-))
>
>> @@ -7667,6 +7668,7 @@ case "$target_name" in
>> TARGET_SYSTBL_ABI=common,nospu,32
>> echo "TARGET_ABI32=y" >> $config_target_mak
>> gdb_xml_files="power64-core.xml power-fpu.xml power-altivec.xml power-spe.xml power-vsx.xml"
>> + deprecated_features="ppc64abi32 ${deprecated_features}"
>
> Maybe prefer
> add_to deprecated_features ppc64abi32
>
> ?
>
>> ;;
>> riscv32)
>> TARGET_BASE_ARCH=riscv
>
> If we just made the deprecation warning be printed by
> generic logic whenever a deprecated target ended up in
> the enabled list then it would be easier to add other deprecated
> targets to the list, as you wouldn't thae also have to find some
> other part of configure like this to set a deprecated_features variable.
>
> (I'll send a patch to add lm32-softmmu,tilegx-linux-user,unicore32-softmmu
> to the deprecated-target list later once we have the mechanism in place.)
>
>> @@ -8011,6 +8013,12 @@ fi
>> touch ninjatool.stamp
>> fi
>>
>> +if test -n "${deprecated_features}"; then
>> + echo "Warning, deprecated features enabled."
>> + echo "Please see docs/system/deprecated.rst"
>> + echo " features: ${deprecated_features}"
>> +fi
>> +
>> # Save the configure command line for later reuse.
>> cat <<EOD >config.status
>> #!/bin/sh
>> --
>
> thanks
> -- PMM
--
Alex Bennée
next prev parent reply other threads:[~2020-09-11 8:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-10 13:14 [PULL 00/10] testing and other mix fixes Alex Bennée
2020-09-10 13:14 ` [PULL 01/10] CODING_STYLE.rst: flesh out our naming conventions Alex Bennée
2020-09-10 13:14 ` [PULL 02/10] usb-host: restrict workaround to new libusb versions Alex Bennée
2020-09-11 8:49 ` Igor Mammedov
2020-09-10 13:14 ` [PULL 03/10] tests/meson.build: fp tests don't need CONFIG_TCG Alex Bennée
2020-09-10 13:14 ` [PULL 04/10] target/mips: simplify gen_compute_imm_branch logic Alex Bennée
2020-09-10 13:14 ` [PULL 05/10] docs/system/deprecated: mark ppc64abi32-linux-user for deprecation Alex Bennée
2020-09-10 13:15 ` [PULL 06/10] configure: don't enable ppc64abi32-linux-user by default Alex Bennée
2020-09-10 20:33 ` Peter Maydell
2020-09-11 8:05 ` Alex Bennée [this message]
2020-09-10 13:15 ` [PULL 07/10] hw/i386: make explicit clearing of pch_rev_id Alex Bennée
2020-09-10 13:15 ` [PULL 08/10] tests: bump avocado version Alex Bennée
2020-09-10 13:15 ` [PULL 09/10] tests/acceptance: Add Test.fetch_asset(cancel_on_missing=True) Alex Bennée
2020-09-10 13:15 ` [PULL 10/10] plugins: move the more involved plugins to contrib Alex Bennée
2020-09-13 19:27 ` [PULL 00/10] testing and other mix fixes Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wo10oi1c.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=f4bug@amsat.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).