> > Btw, I've started to use subversion for my cross-gcc activities. > > Currently it's a local repository in my home directory, but it may > > probably be moved somewhere. > > OK. I'm just sorting out the directories and scriptage to get both the > old and new toolchains apt-able from emdebian.org. > > I also have you cross-toolchain build scripts and files and patches > there in a build dir, but I started pdating the script so it would check > for new gcc releases and try updated builds before realising that this > all gets quite complicated (need to back off and keep the old version if > new builds fail - what do you do if some builds work and some don't) and > failing to finish. > > I'll mail you details on this later nikita. Don't forget that just rebuilding new versions of gcc packages may be not enough - some additional patching may be needed. Currenly I'm using subversion repo, where I keep debian/ directories of gcc packages released by Matthias Klose, and debian/ directories of my corss-gcc work. Besides debian/ dir, the packages only contain upstream tarballs, I decided not to make the repository huge by keeping those in. I try to check in and tag each new package release (in svn, tags are just copies of a directory tree). I then use svn to merge diffs between package releases into my cross-gcc trees, to merge changes in one tree into two other trees, to creatre patches, etc. Because of versioned dependency on gcc-X.Y-base, currently there could be troubles with installing version of cross-gcc "much different" from installed version of native compiler. (There probably is no much technical need for such a dependency, but it exists in native compiler packages, and removing it for cross compiler packages will bloat build scripts even more, which I am trying to avoid.) So it could be a good idea to make constantly available cross-gcc packages for those versions that are currently in sid / testing (and also stable after sarge is released). The process to do so could be something like this. Svn repo should be moved to somewhere from where it would be accessable by onyone interested. Svn trunk for each major gcc version (currently 3.3, 3.4 and 4.0) should correspond to version in sid. When new version is uploaded to sid, it should be merged into trunk (svn is really good at merges). For version currently in testing (and later in stable) svn branch should exist. When version from sid propagates into testing, such branch should be created, and older one removed (svn is good at creating and removing branches). When some (only cross-related) change is comitted into trunk, it should be, if possible, merged into current testing branch (if it differs); svn will make this task trivial. What could be automated: - checkin and tagging of new versions from Matthias; - notifying human that it's time to merge it into trunk; maybe also some reminders that a merge is still pending; - creating and removing branches for versions in testing (and stable) - building current versions from trunk and branches for all supported targets (maybe triggered by commit, or daily if-there-was-commit-since-last-try) - maybe merges (in temporary directory, without commit!) Also preparing -arch-cross packages for build-depends of cross-compiler, from versions currently in sid and testing, should be automated. Of course it would be better if appropriate cross-gcc patches are merged into gcc packages before packages are released. But currently this seems not to be possible (at leased, Matthias seem not to like the idea to give me access to his version control system). Also, Matthias probably won't be happy to have cross support as one more showstopper that prevents such important package as gcc to be uploaded in time. > > > I'd like Nikita to get more involved as he has > > > clearly become the debian-cross-toolchain man :-) > > > > What exactly do you mean? > > > > I'm currently more or less maintaining cross-gcc, cross-binutils and > > dpkg-cross. I'm going to continue these activities, and least in > > forseable future. > > Exactly - and these are all important components of emdebian in that we > want an easyily aptable toolchain and tools. We have this stuff - it's > mostly just a matter of tidying things up a bit and updating the website > to explain what is available, how people install it, what is known to > work and what isn't etc. If you are happy to look after this bit of the > emdebian project so that your work is a bit more visible and accessible > I think that would be great. Well, a wiki is needed :) I may also publish current status information and open tasks. As for apt-able source - see above. Nikita
Attachment:
pgpPQGICuGCgJ.pgp
Description: PGP signature