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.
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.
The amount of %define's we've grown recently does seem to be getting out of hand. I'm not sure it's a good/bad thing, but it does make the spec a little harder to read.
Not sure about your proposal tbh. I'll think about it more when I'm back from vacation :)
Dave
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.
The amount of %define's we've grown recently does seem to be getting out of hand. I'm not sure it's a good/bad thing, but it does make the spec a little harder to read.
Not sure about your proposal tbh. I'll think about it more when I'm back from vacation :)
I like it, at least in theory. Invariably, I'll do a test build, and to speed the process, I twiddle bits at the top of the spec to disable certain builds. In the i686 case, I almost always forget to hunt down lower to turn off pae.
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.
The amount of %define's we've grown recently does seem to be getting out of hand. I'm not sure it's a good/bad thing, but it does make the spec a little harder to read.
Not sure about your proposal tbh. I'll think about it more when I'm back from vacation :)
I like it, at least in theory. Invariably, I'll do a test build, and to speed the process, I twiddle bits at the top of the spec to disable certain builds. In the i686 case, I almost always forget to hunt down lower to turn off pae.
I probably don't really notice, because my workflow for test builds is usually make prep cd kernel-2.6.20/linux-2.6.20.noarch cp configs/$whateverconfigIwant .config make oldconfig bzImage modules sudo make modules_install install
But I've not objection to making it easier for people who don't follow my workflow and do things differently.
Dave
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.
The amount of %define's we've grown recently does seem to be getting out of hand. I'm not sure it's a good/bad thing, but it does make the spec a little harder to read.
Not sure about your proposal tbh. I'll think about it more when I'm back from vacation :)
I like it, at least in theory. Invariably, I'll do a test build, and to speed the process, I twiddle bits at the top of the spec to disable certain builds. In the i686 case, I almost always forget to hunt down lower to turn off pae.
I probably don't really notice, because my workflow for test builds is usually make prep cd kernel-2.6.20/linux-2.6.20.noarch cp configs/$whateverconfigIwant .config make oldconfig bzImage modules sudo make modules_install install
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}...
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.
The amount of %define's we've grown recently does seem to be getting out of hand. I'm not sure it's a good/bad thing, but it does make the spec a little harder to read.
Not sure about your proposal tbh. I'll think about it more when I'm back from vacation :)
I like it, at least in theory. Invariably, I'll do a test build, and to speed the process, I twiddle bits at the top of the spec to disable certain builds. In the i686 case, I almost always forget to hunt down lower to turn off pae.
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...
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...
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 wrote:
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.
I like this; right now there are surprises there for the unwary who think they can disable things that way.
Chuck Ebbert wrote:
Jarod Wilson wrote:
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.
I like this; right now there are surprises there for the unwary who think they can disable things that way.
I've implemented enabling/disabling certain builds at the very top of the spec file, and anything you set to not build at the top will NOT be turned back on later by an ifarch/ifnarch/etc -- all those have been modified such that they only disable things compared with the defaults set at the top.
Turns out the complexity of adding --with/--without support only resulted in the on/off lines at the top of the spec being slightly longer, so one can now additionally pass in, say, --without xen, on the rpmbuild line to disable building a xen kernel. For example, here's the results of a test build using the modified spec:
$ rpmbuild -bb --without xen --without kdump --without debug kernel-2.6.spec [...] Wrote: /data/buildroot/RPMS/x86_64/kernel-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-debuginfo-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-debuginfo-common-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-devel-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-headers-2.6.20-1.2937.fc6.x86_64.rpm Executing(%clean): /bin/sh -e /data/buildroot/tmp/rpm-tmp.44498 + umask 022 + cd /data/buildroot/BUILD + cd kernel-2.6.20 + rm -rf /data/buildroot/tmp/kernel-2.6.20-1.2937.fc6-root + exit 0
Results are exactly as expected/desired. Similar results have been observed on an i686 build.
Here's another thought... Would be simple enough to add one more flag, along the lines of "--without flavo{,u}rs" that automagically flipped off everything but the base kernel build (+debuginfo, devel and headers). That's actually likely to be the thing folks would most commonly want to do. Worth adding?
Still touching up a few things, but should have this completely presentable before lunch tomorrow...
Jarod Wilson wrote:
Chuck Ebbert wrote:
Jarod Wilson wrote:
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.
I like this; right now there are surprises there for the unwary who think they can disable things that way.
I've implemented enabling/disabling certain builds at the very top of the spec file, and anything you set to not build at the top will NOT be turned back on later by an ifarch/ifnarch/etc -- all those have been modified such that they only disable things compared with the defaults set at the top.
Turns out the complexity of adding --with/--without support only resulted in the on/off lines at the top of the spec being slightly longer, so one can now additionally pass in, say, --without xen, on the rpmbuild line to disable building a xen kernel. For example, here's the results of a test build using the modified spec:
$ rpmbuild -bb --without xen --without kdump --without debug kernel-2.6.spec [...] Wrote: /data/buildroot/RPMS/x86_64/kernel-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-debuginfo-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-debuginfo-common-2.6.20-1.2937.fc6.x86_64.rpm
Wrote: /data/buildroot/RPMS/x86_64/kernel-devel-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-headers-2.6.20-1.2937.fc6.x86_64.rpm Executing(%clean): /bin/sh -e /data/buildroot/tmp/rpm-tmp.44498
- umask 022
- cd /data/buildroot/BUILD
- cd kernel-2.6.20
- rm -rf /data/buildroot/tmp/kernel-2.6.20-1.2937.fc6-root
- exit 0
Results are exactly as expected/desired. Similar results have been observed on an i686 build.
Here's another thought... Would be simple enough to add one more flag, along the lines of "--without flavo{,u}rs" that automagically flipped off everything but the base kernel build (+debuginfo, devel and headers). That's actually likely to be the thing folks would most commonly want to do. Worth adding?
An option to do --with=up or --with=smp would be a nice addition if it's not too much added complexity. (That would build only 'up' or 'smp'.)
Chuck Ebbert wrote:
Jarod Wilson wrote:
Chuck Ebbert wrote:
Jarod Wilson wrote:
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.
I like this; right now there are surprises there for the unwary who think they can disable things that way.
I've implemented enabling/disabling certain builds at the very top of the spec file, and anything you set to not build at the top will NOT be turned back on later by an ifarch/ifnarch/etc -- all those have been modified such that they only disable things compared with the defaults set at the top.
Turns out the complexity of adding --with/--without support only resulted in the on/off lines at the top of the spec being slightly longer, so one can now additionally pass in, say, --without xen, on the rpmbuild line to disable building a xen kernel. For example, here's the results of a test build using the modified spec:
$ rpmbuild -bb --without xen --without kdump --without debug kernel-2.6.spec [...] Wrote: /data/buildroot/RPMS/x86_64/kernel-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-debuginfo-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-debuginfo-common-2.6.20-1.2937.fc6.x86_64.rpm
Wrote: /data/buildroot/RPMS/x86_64/kernel-devel-2.6.20-1.2937.fc6.x86_64.rpm Wrote: /data/buildroot/RPMS/x86_64/kernel-headers-2.6.20-1.2937.fc6.x86_64.rpm Executing(%clean): /bin/sh -e /data/buildroot/tmp/rpm-tmp.44498
- umask 022
- cd /data/buildroot/BUILD
- cd kernel-2.6.20
- rm -rf /data/buildroot/tmp/kernel-2.6.20-1.2937.fc6-root
- exit 0
Results are exactly as expected/desired. Similar results have been observed on an i686 build.
Here's another thought... Would be simple enough to add one more flag, along the lines of "--without flavo{,u}rs" that automagically flipped off everything but the base kernel build (+debuginfo, devel and headers). That's actually likely to be the thing folks would most commonly want to do. Worth adding?
An option to do --with=up or --with=smp would be a nice addition if it's not too much added complexity. (That would build only 'up' or 'smp'.)
Done. All changes have been committed to the FC-6 kernel tree, as of build 1.2939. Next up, devel... :)
On Fri, 2007-03-30 at 01:26 -0400, Jarod Wilson wrote:
Turns out the complexity of adding --with/--without support only resulted in the on/off lines at the top of the spec being slightly longer, so one can now additionally pass in, say, --without xen, on the rpmbuild line to disable building a xen kernel. For example, here's the results of a test build using the modified spec:
Cute. That reduces the chances that I commit the local change that's usually in my tree which turns off kdump on ppc64, and smp on ppc32.
How do I get it to work with the Makefile? This doesn't... $ make RPM_DEFINES="--without kdump" ppc64
David Woodhouse wrote:
On Fri, 2007-03-30 at 01:26 -0400, Jarod Wilson wrote:
Turns out the complexity of adding --with/--without support only resulted in the on/off lines at the top of the spec being slightly longer, so one can now additionally pass in, say, --without xen, on the rpmbuild line to disable building a xen kernel. For example, here's the results of a test build using the modified spec:
Cute. That reduces the chances that I commit the local change that's usually in my tree which turns off kdump on ppc64, and smp on ppc32.
How do I get it to work with the Makefile? This doesn't... $ make RPM_DEFINES="--without kdump" ppc64
Hrm, not sure why that doesn't pass the option through, but I hadn't even thought to look at the Makefile to see how these flags would work at that level. Out of curiosity, does the following work?:
$ make RPM_DEFINES="--define 'with_kdump 0'"
I suppose I ought to poke at that some myself... Adding to my todo list.
On Fri, 2007-03-30 at 21:20 -0400, Jarod Wilson wrote:
Hrm, not sure why that doesn't pass the option through, but I hadn't even thought to look at the Makefile to see how these flags would work at that level. Out of curiosity, does the following work?:
$ make RPM_DEFINES="--define 'with_kdump 0'"
I suppose I ought to poke at that some myself... Adding to my todo list.
I used the trick I learned from the end of the existing Makefile...
[root@ps3 devel]# tail -4 Makefile compile compile-short: DIST_DEFINES += --target $(shell uname -m)
ppc64: DIST_DEFINES += --without kdump ppc: DIST_DEFINES += --without smp
Now I just have to remember never to commit the Makefile :)
David Woodhouse wrote:
On Fri, 2007-03-30 at 21:20 -0400, Jarod Wilson wrote:
Hrm, not sure why that doesn't pass the option through, but I hadn't even thought to look at the Makefile to see how these flags would work at that level. Out of curiosity, does the following work?:
$ make RPM_DEFINES="--define 'with_kdump 0'"
I suppose I ought to poke at that some myself... Adding to my todo list.
I used the trick I learned from the end of the existing Makefile...
[root@ps3 devel]# tail -4 Makefile compile compile-short: DIST_DEFINES += --target $(shell uname -m)
ppc64: DIST_DEFINES += --without kdump ppc: DIST_DEFINES += --without smp
Now I just have to remember never to commit the Makefile :)
Ooh, I like it... Along those lines, what if we had Makefile include a Makefile.local if it existed, which was .cvsignore'd? Then you could tweak your local default build prefs to your hearts content without having to worry about accidentally committing them...
/me still needs to actually *read* the Makefile at this point... ;)
Ooh, I like it... Along those lines, what if we had Makefile include a Makefile.local if it existed, which was .cvsignore'd? Then you could tweak your local default build prefs to your hearts content without having to worry about accidentally committing them...
Actually you can write your own that does "include Makefile" and either use "make -f Makefile.local" or just call it GNUmakefile and it will be used in preference to Makefile by default.
kernel@lists.fedoraproject.org
-
Chuck Ebbert -
Dave Jones -
David Woodhouse -
Jarod Wilson -
Roland McGrath