INCLUDE_CONFIG_FILE in GENERIC

[Marcel Moolenaar]

On Jan 15, 2010, at 10:05 AM, M. Warner Losh wrote:
> : Is this really so hard?
> 
> Yes. Didn't you read the message I posted about why this is hard?

No, I didn't.

> There would be a ton of lexer and parser work to make this happen, as
> well as a lot of work to internal data structures to keep the file as
> parsed, rather than as convenient to do config's job.  It is a big
> pita.

PITA != hard. If we're not willing to put in the effort to fix
something, I don't think we should call it hard to do. We should
call it like it is: non-trivial, involved or significant. Heck,
we can even call it a major undertaking. But hard? No, I don't
think it's hard at all.

> I think the way forward isn't as you suggest.

Fine. Just stop trying to classify people as a basis for what
behaviour we should implement. It never works...

> If
> we really make it include everything, then -C can go away, the weird
> pseudo thing we have can go away, and we know get everything.  And it
> is easy to implement...
> 
> Comments?

How does this address the "I don't want everything, I just want
my CVS keyword" example? How does it handle the delicate balance
between space vs. functionality that exists on embedded and/or
low-end platforms. An all inclusive implementation seems not to
take that into account that well. Sure, you can compress but
then you add a runtime overhead to uncompress.

In any case: I personally don't use the option so I really should
not get involved. If I were to implement something from scratch
though, I would treat it as a C file: the config file is the source
and you "compile" it into a binary form suitable for inclusion into
the kernel and you have compile-time options that control the binary
output. No comments will be included in that case and there will be
no option for it. But that's just me...

-- 
Marcel Moolenaar
xcllnt at mac.com