Re: git: 2782ed8f6cd3 - main - dpaa2: fix standalone module build

Hey Bjoern,

On Fri, Oct 21, 2022 at 2:08 PM Bjoern A. Zeeb <bz@freebsd.org> wrote:

> On Fri, 21 Oct 2022, Andrew Turner wrote:
>
> >
> >
> >> On 21 Oct 2022, at 16:17, Bjoern A. Zeeb <bz@FreeBSD.org> wrote:
> >>
> >> On Tue, 18 Oct 2022, Gleb Smirnoff wrote:
> >>
> >>> The branch main has been updated by glebius:
> >>>
> >>> URL:
> https://cgit.FreeBSD.org/src/commit/?id=2782ed8f6cd3d7f59219a783bc7fa7bbfb1fe26f
> >>>
> >>> commit 2782ed8f6cd3d7f59219a783bc7fa7bbfb1fe26f
> >>> Author:     Gleb Smirnoff <glebius@FreeBSD.org>
> >>> AuthorDate: 2022-10-18 05:38:24 +0000
> >>> Commit:     Gleb Smirnoff <glebius@FreeBSD.org>
> >>> CommitDate: 2022-10-18 05:38:24 +0000
> >>>
> >>>   dpaa2: fix standalone module build
> >>> ---
> >>> sys/modules/dpaa2/Makefile | 2 ++
> >>> 1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/sys/modules/dpaa2/Makefile b/sys/modules/dpaa2/Makefile
> >>> index 556a1c531669..fa280452bcfa 100644
> >>> --- a/sys/modules/dpaa2/Makefile
> >>> +++ b/sys/modules/dpaa2/Makefile
> >>> @@ -19,6 +19,8 @@ SRCS+=    memac_mdio_common.c memac_mdio_if.c
> memac_mdio_if.h
> >>>
> >>> SRCS+=      bus_if.h device_if.h miibus_if.h
> >>> SRCS+=      pcib_if.h pci_if.h
> >>> +SRCS+=     mdio_if.h
> >>
> >> What do you need this for?
> >>
> >>> +SRCS+=     opt_acpi.h opt_platform.h
> >>
> >> opt_acpi gets inlcuded lines below and so does opt_platform under the
> >> respective OPT_ checks.  Now they are there twice.
> >
> > OPT_ACPI doesn’t exist as a make variable so the ".if !empty(OPT_ACPI)”
> check won’t work as it is expected to work here so opt_acpi.h won’t be
> built. The second problem is the opt_*.h files need to be unconditionally
> created so they can be included in the relevant code.
>
> Then they should probably have been removed from under the .ifdefs
> in the same commit?
>
>
> We do use OPT_ACPI elsewhere in the tree as well.. hwpmc?  Can't
> remember.  How's it working there?
>
> What is currently then including these files then?  Hmm I haven't used
> the module in a while...
>
> Should we duplicate the FDT logic for ACPI in sys/conf/kern.opts.mk
> so LINT-ACPI can be a better thing long-term as well?
>

Yes. We likely should clean this up... But the appetite to polish the
currently
way over polished and under powered config(8) program is low. However,
having it create a .mk file that can be included that summarizes all the
options in a kernel config would be the least amount of effort relative to
the
crazy greps we have going on now.

Warner