Hi Andrew;

Am Montag, 6. Januar 2014, 19:44:35 schrieb Andrew:
> Hi all.
> 
> At least I've got an idea how to easily maintain different targets with
> different kernels, and how to simplify config/patches/etc storing with
> minimum modifications of logic.

Nice coincidence - I've worked towards a unified kernel for rpi, while you'll 
try to manage diffenrent kernel for the architectures :)

But I do see, the benefits.

And like you,  I've started to use the make/toolchain/*mk files to tweak 
different settings for architectures myself. Looks like those files becomes 
more 
important  - they are not as "static" as they have been.

Needs to be clarified in the docs/wiki.

> I've moved kernel version into make/toolchain/<target>.mk, and added
> __TOOLCHAIN__, __KVER__ and __KBRANCH__ macro handlind to source
> filename and dir into buildtool.cfg <File> section. So, specifying
> different kernel versions into make/toolchain/<target>.mk we can
> maintain targets with different kernels. Also this eliminates userland
> dependency from kernel (except some packages with kernel modules).
> 
> Also I think that it'll be good to add <MultiFile> macro item to specify
> a lot of files in single record (for ex., for kernel sub-arch patches),
> but it seems that it'll require more significant changes into buildenv.
> 
> It seems like all is working; I'll try to rebuild tree.

And did it work?

How far are we away from rebuilding kernel and userland without touching the 
toolchain? This would save a lot time testing stuff.

kp

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk

_______________________________________________
leaf-devel mailing list
leaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Reply via email to