On Thursday 24 May 2007, Sam Ravnborg wrote: > The intent with this is clear but the solution you suggest albeit simple > does not really match where we could end up with kconfig. > Recently Roman added support for options in the kconfig language > and I would assume we could deal with most of this just using options. that certainly sounds nicer :) > One example could be to support options for the mainmenu entrye like this: > > mainmenu "Busybow config system" > option project="Busybox" > option version="$VERSION" <= Where '$' signify an environment variable this is doable now ? if so, i'll test it out in uClibc ... > In this way we could later distribute kconfig as a binary instead > of building it into the source as today. not entirely sure how useful that'd be unless you mean as a completely sep package that distributions would include ... -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
- Follow-Ups:
- Re: [rfe] easier customization of kconfig for non-Linux projects
- From: Sam Ravnborg <[email protected]>
- Re: [rfe] easier customization of kconfig for non-Linux projects
- References:
- [rfe] easier customization of kconfig for non-Linux projects
- From: Mike Frysinger <[email protected]>
- Re: [rfe] easier customization of kconfig for non-Linux projects
- From: Sam Ravnborg <[email protected]>
- [rfe] easier customization of kconfig for non-Linux projects
- Prev by Date: Re: [RFC 2/5] inode reservation v0.1 (ext4 kernel patch)
- Next by Date: RE: [PATCH] [scsi] Remove __GFP_DMA
- Previous by thread: Re: [rfe] easier customization of kconfig for non-Linux projects
- Next by thread: Re: [rfe] easier customization of kconfig for non-Linux projects
- Index(es):