Re: Packaging a library that requires cross-compiled code
On 9/28/07, Ian Jackson <ian@davenant.greenend.org.uk> wrote:
> > 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.
It would be hard work because such a package would be my second ever
debian package. Packaging something as complex as a cross-compiler
with multiple variants doesn't seem like the right second thing to
package.
But, if there is precedent, it might not be too painful to mimick
existing cross-compiler packages to build my own. I'll see what I can
do.
> > 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 ?
It is written in C, with an asm bootstrap. The idea was to basically
download and build an arm7 cross-compiler as a part of running
dpkg-buildpackage. Insane and wrong, don't say it, I know. I was just
being exhaustive as to what had already been suggested.
> > 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.
If I'm going to build a cross-compiler in the process of building my
package, might as well go the extra mile and make the cross-compiler
into a package of its own.
> > 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.
I am trying as hard as possible to think of cases where you would
actually want to change the program, but I'm drawing blank. All the
driver does is the equivalent of "memcpy(flash_addr, ram_addr,
chunk_size); *FLASH_CONTROL = FLASH_WRITE_CMD;". The only thing a user
could do by changing that code is damage the flash chip by messing
with the timing settings.
If packaging the cross-compiler is unavoidable, I'll file an ITP and
try to see how that can be done. But if it goes beyond the time I'm
prepared to put into it, I'll go with option 4, and host it outside
the main debian archive.
- Dave
Reply to: