Paul wrote:
> A little background - On Debian installations, a set of tools have been 
> provided to allow kernel packages to be quickly & simply generated. It is 
> something I do quite regularly with the following steps:
>  * Extract kernel sources in /tmp
>  * Apply patches
>  * Copy an existing .config over - Run `make oldconfig`
>  * make-kpkg binary-arch (produces kernel-image and kernel-header packages)
>  * Install/reboot
> It may sound a long winded method, but it does allow me to use the generated 
> packages to install on any number of other machines.

[Related question from my side:]

Would you be willing to provide debian package generation rules for
Xenomai? Something that would spit out .deb files when calling, say,
"make deb KERNEL=linux-2.6.x.tar.bz2 CONFIG=my-kernel-config" in a
configured userland build directory? That way we could automatise binary
package generation for kernel, user libs, development headers, and
documentation. And that would allow us to finally distribute them for
generic targets like x86 and x86_64 along with the usual tar files.

I think such a feature (maybe later enhanceable by RPM) would both be
interesting for replicable custom installations as well as for a
reference kernel distribution to provide a Xenomai quick-start.

> The problem - creates symlinks to assorted files in the 
> Xenomai source tree. Not a problem if the same tree exists in the same 
> location on the target machine. As yet, there is no xenomai Debian package, 
> and the build location may not be the same as the install location - This 
> results in a large number of dangling symlinks which thwarts attempts to 
> compile out of tree modules using the kernel-headers package. I suspect the 
> same issues would exist for RPM packages and NFS mounted targets.
> A solution - Instead of creating symlinks, the files need to be copied in to 
> the kernel source tree. Most people will use symlinks as it simplifies the 
> `svn up`/make process and avoids having to run prepare-kernel each time. I 
> propose a trivial patch that retains the original behaviour and provides an 
> option to turn off symlinks (patch attached).

Would this build procedure already help you?


Attachment: signature.asc
Description: OpenPGP digital signature

Xenomai-core mailing list

Reply via email to