Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 May 1998 23:52:32 +0200
From:      Eivind Eklund <eivind@yes.no>
To:        Richard Wackerbarth <rkw@dataplex.net>
Cc:        current@FreeBSD.ORG
Subject:   Re: How about /usr/ports/kernel ?
Message-ID:  <19980531235232.04296@follo.net>
In-Reply-To: <l03130310b196ef2053d9@[208.2.87.10]>; from Richard Wackerbarth on Sun, May 31, 1998 at 11:50:33AM -0500
References:  <l03130309b195d4c6fd5b@[208.2.87.10]>; <199805301346.PAA29505@labinfo.iet.unipi.it>; <199805301346.PAA29505@labinfo.iet.unipi.it> <19980530182913.04478@follo.net> <l03130309b195d4c6fd5b@[208.2.87.10]> <19980531052120.41610@follo.net> <l03130310b196ef2053d9@[208.2.87.10]>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 31, 1998 at 11:50:33AM -0500, Richard Wackerbarth wrote:
> At 3:21 AM -0000 5/31/98, Eivind Eklund wrote:
>> On Sat, May 30, 1998 at 03:45:31PM -0500, Richard Wackerbarth wrote:
>>> At 4:29 PM -0000 5/30/98, Eivind Eklund wrote:
>>>
>>> My own view of this is that config(8) should scan for
>>> 	../../*/conf/files.FreeBSD
>>> 	../../*/conf/options.FreeBSD
>>> 	../../*/conf/files.FreeBSD.<architecture>
>>> 	../../*/conf/options.FreeBSD.<architecture>
>>> add concatenate this with the appropriate files.
> 
>> [...on having kernels made as a part of a normal build...]
>> 
>> We've discussed this before (off the list), and I tend to agree to
>> some of it.  However, how is this related to the proposal above
>> (except for both being part of the kernel build structure)?
> 
> I think that it is a "detail". Rather than increasing the complexity
> of "config", I would use the capability of "make" and the preprocessors
> to present to "config", a single list of elements that it must process.

Now I get you.  Yes, I agree this would be preferable given automated
kernel builds (and I agree that automated kernel builds would be
preferable :-)

However, to be able to do automated kernel builds we have to have a
way of specifying which kernels to build which do not come as a shock
to our userbase (this is a political necessity; I don't think either
of us would get any way arguing otherwise).  This probably mean that
we'll have to support the use of config(8) in the way it is presently
used for a transition period of at least a year.

This again mean that if we want to do the above during the next year
(minimum), we'll have to add it to config.  I want the above to be
added yesterday (well, really in time for 2.2.0-RELEASE, that is in
February last year :-)

Do you disagree with the way of adding this meta-information to
contributed subsystems?  I'm all ears for anything better that give
the same capabilites for external people modifying the system - I just
haven't found any better way.


[... deleted: points on Unix and design which I agree with but don't
always find myself bright enough to be able to follow ...]

Eivind.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980531235232.04296>