On 15.12.18 16:37, Ben Hutchings wrote:

Hi,

>> while trying to build a debian kernel w/ some minor config changes>> (actually, just need the gpio keyboard modules), I've stumpled
across>> several strange problems and finally found out that the
patches>> haven't been applied on the main tree (in contrast to rt tree)
.. this>> ate up a lot of time, as the build takes so long
(unfortunately, I don't>> have the luxory of possessing a 120 core
machine ;-)).> > There is a script to do what you want,
debian/bin/test-patches.
Shouldn't the patches be automatically applied when calling the 'binary'
rule (./debian/rules) ? If not, this doesn't seem to make much sense :o

I'm still in the middle of hacking, what I did so far is changing the
build tree for 'none' to a separate directory, just like for 'rt', using
the same rules. (essentially dropping special rules for
$(STAMPS_DIR)/source_none, etc) - now the patches are applied.

The only downside of this change I see so far is that I get yet another
temporary copy of the full source tree. OTOH, I'm thinking about
dropping the initial unpack (in the root dir) and change these rules
to directly unpack from tarball (or optionally pull a git repo).

>> When I look at the build rules, I really wonder why it's all so complex.>>>> Some things that IMHO contribute to that complexity:>>>> * several

source trees - rt vs none:>>   --> can't we do this with one tree ?>>
--> if necessary, fixup the rt patches, so they don't do anything in>>
     non-rt build (eg. proper #ifdef's) ?> > That would be a huge amount
of work to maintain.
Initial work or permanent maintenance ?
I agree that this takes some initial effort, and I'd like to volounteer
for that.

BTW: On a quick look, I've seen that patches from
'debian/patches/series' are not included in in series-rt. Are they
supposed to be
already applied, before the rt tree copy is made ?

>> * auxillary tools>>   --> can't we build them completely separately ?>>       (IMHO,

shouldn't have an hard dependency on currently running>>       kernel)>

> They can be disabled with the "pkg.linux.notools" profile.
Yes, but then they aren't built at all. Fine for my current local case,
but the distro still needs them. So, my proposal is making them
completely own source packages - then we wouldn't need play around w/
profiles anymore and therefore reduce complexity.

>> If it's just a matter of resources, I'd like to join in and do the job.> > If you want to help simplify - and I'm sure some simplification is>
possible - you have to start by understanding why the complexity is>
there in the first place.
Yes, that's why I've started this thread: to ask you guys what that's
really all about :)



--mtx

--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@??? -- +49-151-27565287