Hi Chris,
Thanks for the detailed reply. I have packages called msp430-binutils,
msp430-gcc, msp430-libc, msp430-gdb. These work at present but due to
the gcc version required do not work on jaunty.
My plan of attack if you agree:
All patches are hosted on my server that are submitted, I get a copy of
these and produce a combined patch that keeps getting updated the more
patches that are submitted. This combined patch can work in my packages
plus other packages for other distributions. These combined patches are
kept in Bazaar again on my local server so we have a point to check when
what broke what in a commit. These combined patches would be the best
way to go forward without a release scheme as I can keep track of the
combined patch for the packaging. This combined patch would be checked
into Bazaar onto my server and in the commit log I will log how this
patch was created and where the individual patches came from.
This allows the packages to be created each day and we have some some of
quality checking progress built in to ensure the source is sane before
been built into packages.
So in Bazaar there is the mspgcc4 port. This port works with Karmic and
this is what I need to package to get Karmic support. I will take a look
at what is in Bazaar. As the code there compiled last night I can use
this in my packages. I will also look at combing the other patches as
well such as the ones that have appeared recently for the MSP430x5 and
usb support.
I will bring along more packages for the other tools but at the moment I
am just working on the core parts of the compiler.
When I said the internals, I more meant line for line of the source to
find out how you created the cross compiler. By understanding the source
I was hoping to be able to add new devices when required.
Thanks,
Adam
Chris Liechti wrote:
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
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
