sys/modules: fix bogus OPT_ACPI tests

[jhb]

Summary

ACPI is not handled specially by sys/conf/kern.opts.mk (unlike a few
options), so we should fall back on the generic behavior of
sys/conf/config.mk, which pulls from all the generated opt*.h files,
including opt_acpi.h, which will cause DEV_ACPI to be included in
KERN_OPTS. Then the generic machinery in sys/conf/kmod.mk will cause
SRCS.DEV_ACPI to be included in SRCS when appropriate.

Sponsored by: Microsoft

[imp]

This is fine, but we have two different patterns. For subdirs we use SUBDIR.${MK_FOO}, though we couldn't use that here. And I kinda like this better...

[jhb]

In D38737#881586, @imp wrote:

This is fine, but we have two different patterns. For subdirs we use SUBDIR.${MK_FOO}, though we couldn't use that here. And I kinda like this better...

Humm, I think you are the one that added the helper to make this pattern work. :) I think the way we made the SUBDIR pattern work was by adding 'SUBDIR.yes' or some such where as kmod.mk explicitly walks KERN_OPTS adding SRCS.${OPT}. I think the problem with the SUBDIR case is we may not have an exhaustive list of options handy to walk? Also, making SRCS.yes work for module Makefiles would require adding new MK_FOO variables for each option in KERN_OPTS.

[imp]

In D38737#883371, @jhb wrote:

In D38737#881586, @imp wrote:

This is fine, but we have two different patterns. For subdirs we use SUBDIR.${MK_FOO}, though we couldn't use that here. And I kinda like this better...

Humm, I think you are the one that added the helper to make this pattern work. :) I think the way we made the SUBDIR pattern work was by adding 'SUBDIR.yes' or some such where as kmod.mk explicitly walks KERN_OPTS adding SRCS.${OPT}. I think the problem with the SUBDIR case is we may not have an exhaustive list of options handy to walk? Also, making SRCS.yes work for module Makefiles would require adding new MK_FOO variables for each option in KERN_OPTS.

I tend to agree. I like this method a little better, and we'd have to create a lot more variables than we have now, and I think that would get clunky. bsd.subdir.mk doesn't know about iterating through a list of SUBDIR.foo options, but perhaps it should instead of just adding SUBDIR.yes to the list.

I'm also a little hesitant to add new hacks to the build system since we keep wanting to rewrite it and each one makes that harder. However, this is using an existing hack, one that I think will translate well to what I'd like to see in a new config system.

So don't let my parenthetical remark slow you down.