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? _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
