| Thread Previous • Date Previous • Date Next • Thread Next |
Hi,I have successfully compiled the last two releases of Kicad using Microsoft compilers. There are a number of things I have to do to make it work. My goal here is to make a minimal impact on the source code. You may ask "what is my motivation for doing this?", the following directory listings demonstate the answer clearly.mingw 11/29/2007 11:51 AM 6,303,776 cvpcb.exe 11/29/2007 11:51 AM 6,274,696 gerbview.exe 11/29/2007 11:51 AM 7,471,808 eeschema.exe 11/30/2007 08:16 AM 5,825,800 kicad.exe 11/29/2007 11:51 AM 7,974,909 pcbnew.exe msvc 7.1 12/10/2007 01:02 PM 2,383,872 cvpcb.exe 12/10/2007 11:33 AM 2,359,296 gerbview.exe 12/10/2007 10:31 AM 2,928,640 eeschema.exe 12/10/2007 02:45 PM 2,199,552 kicad.exe 12/10/2007 11:53 AM 3,141,632 pcbnew.exe
This seems unlikely to be an apples to apples comparison. I know that:1) the mingw build is a static linking of the wxWidgets library to the executable. Is the msvc a static or dynamic linking? I'll assume dynamic. Therefore, you would have to add the size of the wxWidgets.DLL to each exe file to get an apples to apples comparison.
2) the mingw build seems to have debugging symbols in the *.exe files. Run the mingw strip.exe program on your windows binaries *.exe to remove another ~3 mbytes per binary.
When running kicad on a Terminal Server, size does matter.
I thought a terminal server ran the app on the server, so the app does not need to travel accross the wire? Are you saying the RAM footprint within the terminal server is an issue? Realize that the 3 mbytes per *.exe of symbols may not be loaded into process space under windows. I don't know why it should be.
Also, it is likely that the sum of the dynamic wxWidgets.DLL and msvc EXE is larger than the size of the statically linked g++ exe simply because the static linking builds in only code that is actually used. Whereas the DLL has to be built as a worse case binary, incorporating everything.
If this still does not persuade you, maybe you can:1) file a bug report with Microsoft, saying their free compiler is less than free (negative free = expensive), in that it won't compile a program that g++ does and it is costing people time. They have more man-hours available to support their compiler than I do.
2) maintain your own patches and apply them each time you need to build. 3) get SVN write permission from Igor and apply them yourself.4) Pray that someone else who does have write access and has time to spend on a Microsoft problem will do this for you.
Dick
| Thread Previous • Date Previous • Date Next • Thread Next |
