Re: [PATCH v2 2/2] Add scripts/oss-fuzz/build.sh

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.06.2024 00:47, Tamas K Lengyel wrote:
> --- /dev/null
> +++ b/scripts/oss-fuzz/build.sh
> @@ -0,0 +1,23 @@
> +#!/bin/bash -eu
> +# SPDX-License-Identifier: Apache-2.0

Hmm. Aiui this line is supposed to make unnecessary ...

> +# Copyright 2024 Google LLC
> +#
> +# Licensed under the Apache License, Version 2.0 (the "License");
> +# you may not use this file except in compliance with the License.
> +# You may obtain a copy of the License at
> +#
> +#      http://www.apache.org/licenses/LICENSE-2.0
> +#
> +# Unless required by applicable law or agreed to in writing, software
> +# distributed under the License is distributed on an "AS IS" BASIS,
> +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> +# See the License for the specific language governing permissions and
> +# limitations under the License.

... all of this text, provided an entry is first put in ./LICENSES/.

> +################################################################################
> +
> +cd xen

This looks to suggest that the expectation is for the script to be invoked
from the root of a xen.git clone. Imo something like

cd $(dirname $0)/../../xen

would be more flexible.

> +./configure --disable-stubdom --disable-pvshim --disable-docs --disable-xen

Going forward we mean to no longer bundle e.g. qemu in release tarballs,
yet I wonder whether passing a couple of --with-system-...= here wouldn't
be better nevertheless.

> +make clang=y -C tools/include
> +make clang=y -C tools/fuzz/x86_instruction_emulator libfuzzer-harness

In how far is it a requirement to have "clang=y" here? Wasn't this question
even asked before? I'm not even sure whether mid- or long-term we mean to
retain that functionality. Overrides of tool chain (components) may better
be done using CC= and friends. Plus perhaps by whoever is invoking this
script?

Jan