RPM and cross-compiling?

[david.hagood at gmail.com]

I am working on an embedded system that uses RPM to manage its setup. All
the work is cross-compilation; no compiles are done within the target
environment.

Developers have a sys-root image, plus a full set of cross-compilation
tools (gcc, binutils, etc.).

What I would like to do is to be able to build packages both for the
target and for the developer's machine - let me give you an example:

Let's say I am building a package that provides libfoo, plus the
development packages. Ideally, I want to create the following set of RPMs:
For the target system:
foo.rpm - installs libfoo.so and any needed runtime on the target, into
/opt/<company name>/lib/
For the developer's host system:
foo_<arch>.rpm - installs libfoo.so for the target into the target's
sysroot (/opt/<company name>/tools/<arch>/sys-root/lib)
foo_<arch>_devel.rpm - installs the headers, linker stubs, man pages, etc
for libfoo. This might be into the sysroot, or somewhere else (I'm open to
suggestions of best practices).

Now, I've thought about just making foo.rpm relocatable, and installing it
with the --prefix command, but I see a couple of issues there:
1) The RPM's arch won't match the developer's machine.
2) If the developer forgets that --prefix, badness could ensue.

Now, I could have 2 spec files: one that builds for the host system, and
one that builds for the target, but it seems to me that is wasted motion:
we are compiling the same set of files, with (hopefully) the same set of
options and compilers twice.

Is there an easy way to handle this sort of cross-development?