Chris Liechti wrote:
Sergey A. Borshch schrieb:
Chris Liechti wrote:
It would be great when some of you could take the time and test this
installer and give feedback. In a test project I noticed code changes,
and it got smaller, but i did not yet fully checked that everything
still runs as expected.
1) text files (sources, linker scripts, readme) need line ending
conversion before generating windows package. Readme file, which appears
in windows notepad just after installation looks curiously.
hm. yeah i built it with LF line endings. need to check if i can build
it with DOS endings again. arghhh such an endless story.. building
software on windoze..
2)make.exe requires cygintl-8.dll, which is not included to installer.
thanks, fixed
I haven't been doing much msp430 programming for a while, so I haven't
been paying much attention to this list recently. But this thread
caught my eye - convenient installers are very important in the windows
world (I work with Windows and Linux, and have built gcc for a number of
different architectures - but I'm not a typical windows user!).
Unfortunately, I am *way* behind on my current projects, and don't have
time to try out the installer and the latest versions of the tools.
However, I have a few comments.
First, why is cygintl-8.dll needed for make at all? Cygwin is a
wondrous beast - it lets programs written for a posix environment
compile almost unchanged under windows. But it also sets the standard
for windows DLL-hell - not even Microsoft's tools can compare with the
inconveniences caused by having different versions of cygwin's many
dll's on your system, used by different programs. When it is possible,
it is *always* preferable to use tools built with mingw.
Mingw does not provide as complete a posix environment as cygwin - in
particular, it does not virtualise the file system, so you don't get
symbolic links or *nix file permissions, and it does not support fork()
- you need to use vfork(). The executables are much smaller, and don't
need external DLL's. They are also much faster - file access is faster,
and cygwin's fork() is very slow because windows does not support it, so
cygwin needs to emulate it.
gcc traditionally needs a few patches to build with mingw, although
current gcc 4.x is much cleaner, I believe. In particular, there are a
couple of forks in collect2 that must be changed to vforks (basically,
fork + exec becomes vfork). There are patches available from the
avr-gcc project that make these changes - they work for other gcc ports
(I used them once for building a coldfire gcc).
One thing to think about with the installer is whether you really want
to install into c:\mspgcc by default, with the compiler under
c:\mspgcc\bin. In embedded development, it is often vitally important
to track compiler versions - a project that builds fine with gcc 3.2
will not necessarily built smoothly with gcc 4.2. I keep all my old
compiler versions on-hand, and include the correct path in my makefiles
- modifications to old projects are therefore compiled with their
original compilers, unless I have good reason to change. avr-gcc's
windows installer uses paths such as c:\WinAVR-20080512 by default,
which makes this easier.
There might be other ideas or tricks you can pick up from the avr-gcc
port, it's library AVR Libc, or the windows setup and installer WinAVR:
http://winavr.sourceforge.net/
http://www.nongnu.org/avr-libc/
I've just persuaded the avr-gcc developers to copy msp430-gcc's
"critical" function attribute - sharing between projects is part of the
beauty of open source.
mvh.,
David
