2.6.35.10-74 compilation (and build) problems

[JD]

On 01/06/2011 07:12 AM, Jarod Wilson wrote:
> On Wed, Jan 05, 2011 at 09:21:16PM -0800, JD wrote:
>> On 01/05/2011 08:47 PM, Jarod Wilson wrote:
>>>  From the kernel spec:
>>>
>>> # Dynamically generate kernel .config files from config-* files
>>> make -f %{SOURCE20} VERSION=%{version} configs
>>>
>>> And Source20 is Makefile.config, from which with a bit of effort, you can
>>> determine the order in which the various config-* files are smashed
>>> together to form the end result .config files.
>>>
>>> I think this topic actually came up once in the past, and an idea to add
>>> an extra layer similar to the 'if rhel' clause in the spec was kicked
>>> around, but never came to fruition. In theory, that file would, if
>>> present, apply additional Kconfig changes from an additional overrides
>>> file. It could be an empty file by default, but obviously named or
>>> documented, so that anyone rebuilding could simply put their assorted
>>> additional config options in there, and they'd always be applied over the
>>> top of the stock config options.
>>>
>> Thank you Jared.
>> It does seem strange to me that after so many years, the packagers
>> have totally ignore the needs of the custom configuration kernel builders.
>> Maybe, now that we are 10 years into the 21st century, the packagers
>> will get around to giving us this sorely needed capability.
> The kernel folks have always been open to additions to the kernel spec if
> they're sane, don't cause any undue burden, and if there's actually enough
> demand to warrant carrying them. To date, nobody has really said much of
> anything about wanting it to be easier to support custom configurations,
> particularly on an ongoing, roll-forward way. So far as I know, most
> people just run stock kernels, and the custom kernel build docs are mainly
> utilized only occasionally for one-off builds. Its really a pretty simple
> addition, its just that no more than one person that I can even vaguely
> recall ever asked about even the possibility of it in the past several
> years.
>
> It basically boils down to this:
>
>      ./merge.pl<my config opts>  <stock config>  >  <merged config>
>
> In the stock kernel,<my config opts>  would simply be empty, so the merge
> operation would do nothing, meaning we don't even need any conditionals,
> just a new empty Source: file and wiring for it in %prep.
>
> Nb: your reply dropped the list cc, and I'll not add it back without your
> express consent. Please feel free to re-add the list cc to any reply to me
> though, I think this discussion *should* still be on the list.
>
Thanx! When I click "Reply", for some reason, it does not
reply to the list. This seems to be the case not only with
this list, but with other lists to which I subscribe
via majordomo.
At any rate, I agree that if it is indeed a burdensome thing
to maintain and roll forward, then the minuscule demand does
not justify the effort.
That said, it just does not seem like a huge burden when all
it has to do is re-arrange a script or two. Once done, I would
venture it would not be so burdensome to carry forward.