Re: [ANNOUNCE] OSELAS.Toolchain() 1.1.0 released

[Robert Schwebel <robert at schwebel dot de>]

Hi,

On Mon, Mar 05, 2007 at 09:32:46PM +0100, Jan-Benedict Glaw wrote:
> On Mon, 2007-03-05 16:17:50 +0100, Robert Schwebel <robert@schwebel.de> wrote:
> > Hildesheim, Germany - Pengutronix has released version 1.1.0 of the Open
> > Source GNU toolchain build system OSELAS.Toolchain(). It can be used to
> > build cross compilers for a variety of embedded Linux systems, the
> > complete feature matrix and homepage of the project is on
> > 
> >         http://www.pengutronix.de/oselas/toolchain/index_en.html
> 
> On a first view, the scripts and Makefiles look quite clean. 

I hope so :-) Our first attempt was to start with crosstool and clean it
up in a step-by-step way, but after having tried several possibilities
it turned out that

- crosstool has a bunch of hacks which are poorly documented; they may
  be necessary to build 2.95.3 or some other old gcc version, but nobody
  knows if they are necessary today (and it is our aim to build
  toolchains recent enough that they are a) usable for real-life
  projects and b) close enough to upstream that our patches can be
  integrated)

- the more we tried to cleanup crosstool, it turned out that all we
  needed was already there in PTXdist:

	* a dependency mechanism (just add 'select FOO' to BAR's .in
	  file if you want an autogenerated dependency)

	* a staging structure (get, prepare, extract, compile, install,
	  targetinstall) 

	* an automatic patch mechanism (just throw your quilt-style
	  patch stack into patches/$PACKET/generic/ and it is
	  automatically applied)

	* a set of sophisticated makefiles which allow to misuse ptxdist
	  to build something which is different from what it was
	  intended to (Linux userlands) by having an overwrite mechanism
	  (in ptxdist, project specific .make files overwrite ptxdist
	  supplied ones and you can define your own Kconfig structure).

	* a clear separation of host (runs on the development machine)
	  vs. cross (runs on development machine but builds for the
	  target architecture) vs. target (runs on the target
	  architecture) packets.

So what we now have is a clear per-packet structure:

	cross-binutils{.in,.make}
	cross-gcc-first{.in,.make}
	cross-gcc-second{.in,.make}
	cross-gdb{.in,.make}
	cross-toolchain{.in,.make}
	gdb.make
	glibc-crt{.in,.make}
	glibc-final{.in,.make}
	glibc-headers{.in,.make}
	glibc{.in,.make}
	glibc-linuxthreads{.in,.make}
	glibc-ports{.in,.make}
	kernel-headers{.in,.make}

Each one cares about exactly what it says and has it's own corresponding
directory in patches/.

There are tons of predefined toolchain combinations in ptxconfigs/, and
selecting one of them is just

	ptxdist select ptxconfigs/my_favourite_toolchain

and running

	ptxdist go

which builds the toolchain into /opt/OSELAS.Toolchain-1.1.0/*, following
the old structure from crosstool (we felt that it is better to see on a
higher directory level for which architecture the toolchain is, because
you usually have for example an arm-v4t board and want to look which
toolchains are available via tab expansion, instead of first deciding
that you want to use gcc-4.1.2 and then check which architectures are
available).

> Is it planed to allow building right off CVS/SVN/GIT trunk sandboxes
> of the projects (gcc, binutils+gdb, glibc, linux)?

There is no generic method yet, but you can probably tweak it like this:
You can use file:// style URLs for the packets, and changing for example

CROSS_GCC_FIRST_URL := file://$(PTXDIST_WORKSPACE)/sandbox/gcc/

in cross-gcc-first.make makes this your working directory. PTXdist
checks if file urls point to files (which are taken as tarballs and
extracted to build-{target,host,cross}) or directories; if they are
directories, they are just linked into the corresponding build dirs.
I'm just not sure if it works for packets which are used more than one
time. Just try it out.

The "clean" solution is probably that you add a config switch which says
something like

[ ] use custom URL

and, if being enabled, enables a second, string type, config entry which
lets you enter the URL. The makefile then has to decide which one to
use.

What also dosen't work out of the box at the moment is using gcc
snapshots. You'll notice if you select the gcc-4.2-* snapshots, which
don't download automatically. So what we currently do is to download
them manually and put them into the source dir, which can be configured
with 'ptxdist setup' -> source dir.

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9


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