Re: [crosstool-ng] How to create a RPM of a toolchain

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Laurent, All,

[Laurent, the canonical address for the list is crossgcc@sourceware.org]

On Wednesday 24 March 2010 15:42:54 Laurent Charpentier wrote:
> I successfully created a toolchain with crosstool-ng (thanks a lot to the
> crosstool-ng team :).

Cheers! :-)

> To ease deployment of this toolchain I would like to create a RPM
> containing the whole toolchain files/directories.
> 
> Question: How to create a RPM of the whole toolchain?

I don't speak RPM myself, sorry.

When I have to deploy a toolchain to different machines, I:
 - either build the toolchain on every machines,
 - or make a tarball of the toolchain

The first option is valid if you have many different systems, while
the second applies if all the machines are similar enough.

Note that, the toolchain is fully relocatable, so the tarball can be
extracted on the developpers machine where they see fit, although
having a common setup across the whole development team is a sign
that there is a process inplace, while leaving all the developpers
free to do as they want is a bit of an anarchy.

> Is it possible to break down the whole toolchain RPM into several RPMs,
> having one RPM for each component of the toolchain (e.g. gcc.rpm,
> binutils.rpm, glibc-devel.rpm, ...).

There is no provision for doing that right now, and I don't see it changing
in a near future, if at all. The toolchain is intended to be a single entity
that is not splitable.

What one might envision is the toolchain part ( kernel headers + binutils +
libc + gcc ) being bundled separately from the tools (gdb / dmalloc / ... ),
and the tools being clearly separated one from the others.

There is no reason to split the toolchain part into its different components
as it is really a single thing. For example, a desktop Linux distro will
split the libc runtime from the libc [headers + static libs] part because it
makes sense, but a cross toolchain (IMNSHO) does not follow this principles.

> FYI rpmbuild works from a SPEC file (not from already-made binary files) and
> then runs the full build using this file.

You could trick rpmbuild into considering the generated toolchain to be
source files, and provide a kind of 'build+install' procedure that just
copies the toolchain files so rpmbuild can create it.

Or you could provide a 'buid+install' procedure that uses crosstool-NG
sources as the source for building the toolchain, and have rpmbuild
bundle the resulting toolchain. Just a bit convoluted, but completed
justifiable in this case.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'



--
For unsubscribe information see http://sourceware.org/lists.html#faq