Am 26.10.2002 06:58:19, schrieb "J.C. Wren" <[email protected]>:
> You are correct, it's the Makefile that needs to be edited. BTW, >convention says that the name should be Makefile, rather than makefile, if >you want to follow tradition. heh, i try to avoid the shift key ;-) so its all in small letters (as you can see in my writing here too :-) and it's tradition to name it README but i added the .txt extensions for the windows users... > A couple of other notes. I had to install python2-devel to be able to >generate the _parjtag.so file. Otherwise, it was throwing up on my shoes >with the errors below. This needs to be in the top level README. hm. actualy it's the distutils python package. the debian people decided to split it up and make a separate package with it. it's installed with the standard python distribution on other systems. > The Makefile in the /python directory does the following: 'cp >build/lib.linux-i686-2.1/$@ .' This does not work so well if you have a >python2.2 distribution installed. i know. it was for convenience for me. actualy "setup.py install" could be executed so that the module would be installed so that it's found from any python script anywhere. > The last option in the jtag.py -h has -w which says "Wait for <ENTER> >before closing serial port.". I don't know if this option is applicable to >the parallel port, but obviously serial should be parallel. yes you're right, i obviously took the pybsl sources as a start ;-) i left the option because i wanted some compatibility between the jatg and the bsl tool. > BTW, I hope my comments and whinging are not interpeted as complaints. nobody said that the software we have is perfect but it's a start. and it's open source so anyone is free to improve it. i'll try to fix as much as i can but it's not always that easy. remember that we want to support a number of different platforms. many of them which i don't have access to. i know that the tools should have an installaltion i.e. "make install" but i have never done that on un*x. also binary downloads for the major platforms would be nice (rpm, deb, wininst) but that all needs some time and knowledge to setup. anybody, feel free to help us. > Not all embedded folks are going to be Linux savvy. While I used to do > a >fair amount of Perl programming, I am not a Python person. I would love to >have time to help in the development of the tool chain, but at this point in >my project life cycle, I can only be a user. So when a python script (a >language I don't know) acts up, I'm often at a loss. well python is very easy to learn and very powerful in use. it's saves me a lot of time in my projects. but of course in the case of mspgcc it should be possible to use all the tools without knowing what's behind them. > Especially when it's >dependent on a particular version of Python, or some Windows oddities. we try to avoid such cases, but there may be a _minmal_ version requirement for certain software. chris
