- David L Norris
- Indianapolis, Indiana, United States
Semi-topical babble about Radio, Computers, Linux, Life, the Universe, and Everything.
Previous Posts
Archived Posts
Netflix - Movies At Home
Netflix - Next In Queue
2005-06-03
Swish-e for Windows
So, I've got Swish-e codebase in Swish-e CVS building for Windows completely on Linux including the SWISH::API for Perl. There are a few reasons for me wanting to dump MSVC and cross-compile everything from Linux:
Contributors of some significant batches of code (Swish-d Cluster, SwishCtl, etc) have stated that they would not have been able to contribute code back to the community had Swish-e not been under GPL. We don't want to prevent people from using Swish-e. Some of us just don't want a proprietary program being deeply integrated with Swish-e. For instance, there is one Swish-e ActiveX control which relies on an expensive, proprietary library. Those users are stuck with their ancient version of Swish-e because they can't drop in a newer version. We would like Open Source software such as PHP and Python to be able to link to libswish-e. Indeed, even the swish_php code written by Jose is under the GPL-incompatible PHP open source license. (Open Source != Free Software: GPL taints most open source licenses.) So we invoked the "linking over controlled interfaces" exception to GPL that allows any program (proprietary, open source, etc) to link to Swish-e but only if that program uses the documented interfaces (libswish-e). We have our GPL and everyone has access to the search interfaces.
I built this the other day to test release on Linux:
http://webaugur.com/wares/files/swish-e/swish-e-2.5.4-2005-06-01.exe
That build of swish-e.exe is linked to libswish-e-2.dll or whatever it's named. I think I'll add an optional development section to the installer for swish-e.h and libswish-e.dll.a and whatever else might be handy. (Suggestions are welcome.) The MSVC folks will probably be left to fend for themselves from now on. I'll see if I can make it easier for them to generate a DLL import library.
Why don't I like MSVC? MSVC creates tons of busy work and needless distractions. Visual Studio can be handy for debugging but they removed Makefile support in MSVC 6. So you can choose to be trapped inside of their horrible manually-operated GUI for all eternity or you can abandon their debugger and manually write Makefiles. And since the last few releases of GCC, GDB, binutils, etc work almost flawlessly with Windows I see no point in ever bothering again with MSVC. What's more, with GCC you can do useful things like cross-compile Windows executables from Linux and cross-compile Linux executables from Windows. Pick just about any two computer systems in existence and you can cross-compile between them.
It took me 45 minutes just to test the perl stuff the other day. Maybe 3 minutes of actual testing and I wasted the rest of the time rebooting Windows. When I hold down backspace or press a key combo at just the right moment Windows goes into a tight loop and consumes 100% CPU until I kill it. Seems like something to do with IRQs and memory allocation. It's almost as if VMware is triggering events too fast for Windows to keep up. If I increase /dev/shm to 2 GB and instruct the vm to use it for temp space (instead of /tmp on a hard disk) then it doesn't lock up quite so often. I think more RAM would help more than anything.
- Convenience: it's completely automated and I can provide the Perl and C API with daily snapshot builds.
- I don't use Windows. I hate MSVC. And combining the two makes my blood boil.
- We use libtool with our autoconf build. Building a DLL using libtool is utterly trivial. MSVC seems to require a master's degree in technical frobnication to build a working DLL.
- I don't want to rely on proprietary tools for any part of the build process.
- Most importantly, as of the next release (2.4.4) we will need to provide a DLL on Windows to make it easier to comply with the new Swish-e licensing.
Contributors of some significant batches of code (Swish-d Cluster, SwishCtl, etc) have stated that they would not have been able to contribute code back to the community had Swish-e not been under GPL. We don't want to prevent people from using Swish-e. Some of us just don't want a proprietary program being deeply integrated with Swish-e. For instance, there is one Swish-e ActiveX control which relies on an expensive, proprietary library. Those users are stuck with their ancient version of Swish-e because they can't drop in a newer version. We would like Open Source software such as PHP and Python to be able to link to libswish-e. Indeed, even the swish_php code written by Jose is under the GPL-incompatible PHP open source license. (Open Source != Free Software: GPL taints most open source licenses.) So we invoked the "linking over controlled interfaces" exception to GPL that allows any program (proprietary, open source, etc) to link to Swish-e but only if that program uses the documented interfaces (libswish-e). We have our GPL and everyone has access to the search interfaces.
I built this the other day to test release on Linux:
http://webaugur.com/wares/files/swish-e/swish-e-2.5.4-2005-06-01.exe
That build of swish-e.exe is linked to libswish-e-2.dll or whatever it's named. I think I'll add an optional development section to the installer for swish-e.h and libswish-e.dll.a and whatever else might be handy. (Suggestions are welcome.) The MSVC folks will probably be left to fend for themselves from now on. I'll see if I can make it easier for them to generate a DLL import library.
Why don't I like MSVC? MSVC creates tons of busy work and needless distractions. Visual Studio can be handy for debugging but they removed Makefile support in MSVC 6. So you can choose to be trapped inside of their horrible manually-operated GUI for all eternity or you can abandon their debugger and manually write Makefiles. And since the last few releases of GCC, GDB, binutils, etc work almost flawlessly with Windows I see no point in ever bothering again with MSVC. What's more, with GCC you can do useful things like cross-compile Windows executables from Linux and cross-compile Linux executables from Windows. Pick just about any two computer systems in existence and you can cross-compile between them.
It took me 45 minutes just to test the perl stuff the other day. Maybe 3 minutes of actual testing and I wasted the rest of the time rebooting Windows. When I hold down backspace or press a key combo at just the right moment Windows goes into a tight loop and consumes 100% CPU until I kill it. Seems like something to do with IRQs and memory allocation. It's almost as if VMware is triggering events too fast for Windows to keep up. If I increase /dev/shm to 2 GB and instruct the vm to use it for temp space (instead of /tmp on a hard disk) then it doesn't lock up quite so often. I think more RAM would help more than anything.