David Anderson writes ("Packaging a library that requires cross-compiled code"): > 2) Package an arm7 cross-compiling gcc with just the right set of > options, integrate that with the packaging tools, and then package > with a Build-Depends on the cross-compiler. > > Pro: feels like the Right Way, in a perfect world. Cons: opens the > floodgates of packaging cross-compilers, likely requires > additions/modifications to packaging tools, and takes way more time > than I'm personally ready to put into packaging my code.
This is the right answer I think. Several other embedded systems already have cross-compilers in Debian, so this isn't opening any floodgates or getting into anything too unusual. I can see why it would be hard work for you to learn about packaging cross-compilers. > 3) Somehow make the packaging tools properly cross-compile the .bin > without having a cross-compiler package around. This was briefly > suggested on #debian-mentors, but I have no idea how this would be > implemented. It's not clear what you mean here. 136 bytes seems very little. Is it written in an assembly language or in C ? > Pros: less time involved than 2), would make the package > self-contained. Cons: building a cross-compiler in the packaging > process just to build a 136 byte binary blob feels like killing a flea > with a bazooka, and makes building the package much, much longer than > it should be, given the amount of code and logic it actually carries. Yes, but I think that sounds like an acceptable alternative. > 1) Ship a built copy of the code in the package's .diff.gz, and DTRT > at package creation time to move the .bin from debian/ to the right > place in the staging tree. The source code for the .bin is in > .orig.tar.gz, under a free license. Anyone is free to modify or > rebuild the .bin, provided they obtain an arm7 cross-compiler by > non-debian means (instructions provided). People who just want to > rebuild the package can do so, without caring that there is > cross-compiled code involved. > > Pro: dead simple, the packaging problem goes away. Con: means shipping > a binary blob in the source distribution, which appears to be frowned > upon, regardless of whether the source is also freely available in the > source distribution. This is (unfortunately for you) not acceptable for Debian proper. Everything in Debian must be buildable from source using tools in Debian. > 4) Give up and stay away from the Debian main repositories, just put > the package up on a private package repository. > > Pro: trivial solution. Cons: I'd like to do things right rather than > cobbling something together. You could put the package in contrib. I think contrib would be a possibility for this. But it's far from ideal - think of the poor users who want to change the 136-byte loader program. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]