Jarod Wilson wrote:
> Chuck Ebbert wrote:
>> Jarod Wilson wrote:
>>> Dave Jones wrote:
>>>> On Thu, Mar 29, 2007 at 02:06:58PM -0400, Jarod Wilson wrote:
>>>> > Dave Jones wrote:
>>>> > > On Thu, Mar 29, 2007 at 01:41:45PM -0400, Chuck Ebbert wrote:
>>>> > > > I was thinking about adding something like this to the .spec file
>>>> > > > at the beginning:
>>>> > > >
>>>> > > > %define allowup 1
>>>> > > > %define allowsmp 1
>>>> > > > %define allowpae 1
>>>> > > > %define allowxen 1
>>>> > > > %define allowdoc 1
>>>> > > > %define allowdump 1
>>>> > > > %define allowheaders 1
>>>> > > > %define allowdebug 1
>>>> > > >
>>>> > > > Then, after all the automatic enable/disable of various options is
>>>> done,
>>>> > > > turn off everything that's not allowed.
>>>> > > >
>>>> > > > This would make it much easier to change what gets built.
> [...]
>>>> But I've not objection to making it easier for people who don't follow
>>>> my workflow and do things differently.
>>> Rather than wasting Chuck's time implementing this, what say a
>>> lower-level grunt like myself try to implement something along these
>>> lines? :) I've got a few ideas on how to do it using either %bcond or
>>> %with{,out}...
>> You understand rpm better than I do, so go for it. I'd use Dave's method
>> but an RPM is so much more convenient...
>
> Cool, I'm on it...There are a few ways to approach this... The minimalist approach that comes to mind is to make all the %define build* bits all set to 1/enabled by default, and only flip them to disabled where appropriate, so they'd be equivalent to your allow* idea, in that if you disable them at the top of the spec, they'd stay disabled. The all-out approach is to implement support for --with/--without on the rpmbuild line. Nice to have, but adds complexity/legibility issues to the spec (not that this isn't already a very hard to read spec...), and I'm not sure if I'd actually use it or not. Any strong preference for one route or the other? (Or yet another) -- Jarod Wilson [EMAIL PROTECTED]
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Fedora-kernel-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/fedora-kernel-list
