All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.