[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: toolchain/50731: config(8) adds bogus directories to include path
The following reply was made to PR toolchain/50731; it has been noted by GNATS.
From: Rin Okuyama <okuyama%flex.phys.tohoku.ac.jp@localhost>
Subject: Re: toolchain/50731: config(8) adds bogus directories to include path
Date: Tue, 2 Feb 2016 21:43:25 +0900
On 2016/02/02 19:50, Masao Uebayashi wrote:
> This is partially because NetBSD has no good API for external kernel modules.
> > Both of them are used in order to strip off
> > lengthy paths from "file" statements, and not intended to indicate extra
> > include path. If one wants to add some directory to include path,
> > conditional "makeoptions" statement should be used as follows:
> > % cat sys/external/bsd/acpica/conf/files.acpica
> > ...
> > makeoptions acpi CPPFLAGS+="-I$S/external/bsd/acpica/dist/include"
> > ...
> > %
> > I think the current behavior of "prefix" statement is too much; it merely
> > leads to undesired side effects.
> I don't like "makeoptions" in general, because it can do anything.
> Anything using "makeoptions" is a hack, IMO.
> It would be nice if such a thing can be done in config(5); for
> example, per-module "compile-with", instead of per-file.
Thank you for your comment. I agree with you about "makeoptions". I don't
intend to encourage abuse of "makeoptions".
I just mean that we should register a directory into include path, only
if it is actually required. The "prefix" statement unconditionally adds
its argument to EXTRA_INCLUDES. As a result, for example, the directory
of libx86emu is registered into include path even for vax!
The simplest solution would be (1) stop "prefix" emitting include path,
and (2) add a sentence like this:
emitinclude acpi external/bsd/acpica/dist/include
However, you prefer to more sophisticated framework or notation for
external kernel modules, don't you?
Main Index |
Thread Index |