> > > - Could we add a file say debian/cross/target, that contains the > > > target name and if this file excists the package will compile into a > > > corss-compiler even if the GCC_TARGET environment variable is not > > > set. If that file does not excist the package will compile into it's > > > normal native compiler. > > > > It's not difficult, but what for? > > Toolchain-source scripts may set GCC_TARGET (as well as they may > > create debian/cross/target) > > Well what toolchain dose is to create a source package that builds into > a corss compiler. Once it is craete it should be possible to build it > using things like debuild so no toolcian-source specific scripts will be > invoked that can set GCC_TARGET. I want this generated package to be as > identical as possible to the gcc source package with the cross specifc > parts as separated as possible so that changes can be incoporated > easily. What I am thinking of is a gcc source package with a > debian/cross dir with the corss specifc parts. Ok, I've added such possibility. I've just finished current iteration of work (not 3.3 and 3.4 again build ok for al debian linux targets) and submitted patches to Matthias; support for debian/target is there. > > > - toolchain-source is also use to generate compilers for non-debian > > > architectures. So I would need some way to get the package to > > > build for any GNU system type using some minimal set of patches and > > > configure arguments. > > > > Well, some not-very small fixes wii be needed for that. When I wrote those, I mean "high quality packages". I'm trying to make cross compiler packages non less quality than any other debian package. With all deps set correctly, etc. Debian is known for it's quality, and debian cross-toolchain should not be exception here. To add support for a new (probably non-debian) target, at least the following should IMO be done: - decide which debs are being built, how they are named, which files will be in, where those files should be installed - ensure that binutils deb for target is buildable, and contains tools that look for libs (and other stuff) in correct places - make source package "complete" (have correct build-depends and buildable by sbuild) - make sure that resulting cross-compiler debs work immidiatly after installation and nothing other than installing all dependencies is needed. I hope that currently cross-compiler packages for debian linux targets meet this level of quality. In such context, patches you've sent are only a small part of what's needed. E.g., for newlib, it should be somehow packaged, maybe compiler binaries should be renamed to distinguish from glibc versions, etc Or maybe I'm asking for too much? I think that step 1 should be addition dpkg-architecture wrapper to dpkg-cross, that will allow to define new 'architectures' in a configuration file. It should allow to add, say, 'arm-uclibc' architecture, that will: - represent arm binaries built against uclibc - have tools with named with 'arm-linux-uclibc-' prefix - cross libs packages will be called '*-arm-uclibc-cross' (this follows existing -arch-cross naming, arch is 'arm-uclibc' here) - binutils-arm-uclibc-linux package should be built that will provide arm-uclibc-linux-ld that looks into /usr/arm-uclibc-linux/lib/, etc - and dpkg-buildpackage -aarm-uclibc should be enough to build any 'good' debian source package for this 'architecture'. Other architectures could be added in similar way. Including CPUs for which there is no debian port. -uclibc and -newlib suffixes may be reserved for these libc's; those could be recognized by cross-binutils and cross-gcc deb building scripts to do appropriate jobs. E.g. in case of newlib, it should enable build and packaging of newlib; for both newlib and uclibc it should generate appropriate package relationships, etc. > > > > I was thinking about adding both support for non-debian targets and > > support for libc's other than glibc. Both into gcc and dpkg-cross > > packages (creating, say, 'arm-uclibc' architecture and similar > > (dpkg-cross -b may not be very useful for such 'architectures', but > > dpkg-buildpackage may be very useful - espessialy if we divert > > dpkg-architecture to support those). Even complete toolchain bootstrap > > may be possible (create a 'gcc-lite' deb with -Dinhinit_libc, use it > > to cross-compile libc deb, then create complete gcc). > > That would be realy something! > > > This is probably a good idea - if you see practical uses for it. Maybe > > one such practical use may be to clean up current debian/ dir of gcc > > source packages :). > > Yes it will allow us to have separately maintained corss packages where > the cross maintianer can maintian the settings in the debin/cross dir > will keeping up with the chnages made to the gcc package. Well, with my current knowledge of debian/ directory structure of gcc source packages, I can't say what exactly should go into debian/cross and how things should be done. I'm currently against major redesigns, I think keeping native-gcc and cross-gcc intergated is more important. Nikita
Attachment:
pgpxGxNAeb7M7.pgp
Description: PGP signature