Hi all. Now we have building of toolchain, userlevel apps and kernel (with modules) as similar targets, with same logic. But for future embedded platforms with same/similar CPU arch (but with multiple kernels - for each SoC required separate kernel, possible even with different versions - like rpi case) it causes some troubles. Also rebuilding from scratch taints also toolchain - ~20-30% of rebuilding time.
I think that it'll be good if we'll separate building of toolchain, kernel(+modules) and userland into 3 different procedures. For this, I propose to do next things: 1) Add 3 targets - 'build-toolchain', 'build-userspace', 'build-kernel' instead of single 'build'; for toolchain - 'build-userspace' will just install libs'headers from toolchain dir into staging dir. This should allow to quickly rebuild only userspace soft, or only kernel, or all except toolchain. 2) Add tarball with kernel headers into toolchain instead of headers generation from linux source (it shouldn't produce any pbs - at least for some years of Gentoo usage I didn't saw pbs if headers were older than kernel sources or packages were built with older headers; and more - it's usual situation in Gentoo). This will remove pain of multiple kernel versions into single tree and remove toolchain dependency from linux kernel. 3) Add possibility to specify arch/version of kernel to build via cmdline, and specify list of available major versions (for ex., 3.4, 3.6 and so on) with default one in platform makefile (currently I don't know optimal method to do this). Also this should affect buildpackage.pl. I'll be glad to hear your ideas about this. ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel