This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |