Adam Horden schrieb: > The Bazaar code has been away for over a week now so I have turned off > my automatic package building for now. I do not have packages for karmic > as I did not know the state of the source code. What did happen to the > code in Bazaar?
good question... i don't know why the web interface sometimes gives error messages about revisions that never existed in the repo and sometimes show "no revisions". anyways i wiped the repo created a new shared repo and uploaded the branches again. you once asked about a way to list the branches. the following works now (but it is slow): $ bzr branches bzr://mspgcc.bzr.sourceforge.net/bzrroot/mspgcc > I am still working on packaging but at the same time I am trying to > understand some of the internals so I can better understand how the > cross compiler works. hm. roughly these parts play together: Core parts: - cross assembler and tools (binutils) - cross compiler (gcc) - separate libraries for the target - msp430-libc (must have) - libmspgcc (optional) - there is also libgcc but that is included in the cross gcc Debugger: - cross debugger (gdb) (understanding the target processors asm etc, built in simulator..) Separate tools: - separate tools (msp430-jtag/bsl, ...) - other 3rd party tools not hosted with mspgcc - mspgcc docs and example code - "make" or some other build control tool, usually not dependent on target platform, so no cross versions needed here how to package this? that depends on how many packages you prefer. fine grained packaging could mean approximately a package per list item above. otherwise binutils, gcc, libc, libmspgcc together may make sense. docs+examples as an other package. gdb and gdbproxy maybe? i would package all the python tools separately (as one) as well as each other 3rd party tool as these are more or less independent of the compiler/assembler toolchain used an they may be us use for users of other toolchains. sorry if that wasn't what you asked about :-) >> As far as my understanding goes most of the compilation problems are >> caused by dependencies and interfaces with out-of-project code like the >> kernel, bin-utils, gcc, and the secret libhil.so / msp430.dll code. the libhil used by MSP430mspgcc is completely open source. and i think it was compatible to the HIL used by TI's MSP430. the APIs drifted away when they added spy-bi-wire support. The USB access code is built into the MSP430 library itself. but the complete library is closed source. that's TI's choice. not ours ;-) due to the licensing, gdbproxy was required and as it has to link about the "secret" MSP430 API it also has a closed source part. There were not made using reverse engineering but with the help from TI. so there is no option releasing these part without their consent. there should not be any other parts that are "secret" or depending or have difficult dependencies. >> I always wondered why all these interfaces are needed (and why >> hacks around the TI secret code were not already included ;-) ). one part is explained above. >>> So what is the state of the source code in Bazaar? so far there are no new features in the bzr branch yet (except...) - the mspgcc4 fork was merged into the mspgcc-core branch. but the msp430X branch is still separate for gcc itself - i've tried to get it better structured and separate parts in separate branches. - the build shell script is derived from mspgcc4 (instead of the make variant i usually used from packaging) - i had problems getting a 4.x gcc cross compiler (issues with gcc not finding its own binaries, build itself seems to pass sucessfully) - windows installer files not yet present as i'd like to create a more fine grained packaging there too. >>> Now I asked for advice if this code in Bazaar would be ready for >>> packaging but never got a reply. i myself feel responsible for the python-mspgcc-tools. and i plan to develop them in bzr. gcc, gdb and binutils are an other topic as the key contributors are other developers, several over time. they that want to work further on it have to be happy with the versioning system. so far the feedback has not been very positive in favor of bzr but on the other side, generally, going away from CVS would be preferred. >>> I also asked if it was possible to sort >>> out a release system and Rob Spanton agreed on this but nothing moved >>> forward. As a packager it gives me a headache tracking my own revision >>> numbers to a revision in Bazaar or CVS. so far there have not been "hard" release points so i used dates for the windows installer. with finer grained packages that should get easier. >>> There are commits that break things from time to time so building them >>> each day is a bad idea. We need a release schedule. I have been there >>> with my packages and it requires human intervention as I have them >>> automatically built but for testing I have to update my development >>> machines packages versions then test them to ensure nothing broke before >>> uploading them to Launchpad. a good point. currently there is no official plan for future features (they get included as someone provides patches/checks in). chris
