Building the C++ SP
This topic is primarily to assist in building the C++ ServiceProvider implementation. Use of autoconf and libtool simplifies this process, but Unix and C++ are uneasy partners and occasionally problems crop up, particular when porting to platforms without good libtool support. There are also numerous dependencies, so the process can take some time.
General build advice for dealing with C++
- Use recent stable versions of components whenever possible.
- Try and build using the SRPMs before resorting to the tarballs.
- If a bleeding edge compiler won't work, then fall back to something more tested, or just ask first. The newer, the stricter, but I always try to fix code that's not strictly correct.
- Always maximize the use of shared libraries and --enable-shared when building anything (if it's an option).
- ALWAYS enable/activate support for POSIX threads and reentrant system calls in every single piece of code that is potentially used with Home. If in doubt, don't ask "if it matters". Trust me, it matters. Your system simply will not be stable unless you do this.
Platform-Specific Notes and Issues
- Source RPMs
The current code base circa ShibOnedotThree is still targeting Visual Studio 6.0. Yes, it's very old, but it's stable and most other open source projects are stuck on it or use cygwin gcc because the MS compiler wasn't free. The next programming task is to port to a newer MS compiler, after which the older build will be deprecated. The entire system has been built cleanly on VS 2003.NET, but VS 2005 is now out, and seems to provide a more modern set of defaults, including built-in manifests that help resolve DLL conflicts on newer versions of Windows.
For specifics, see WindowsNotes#ServiceProvider.
Building the Java version is mostly routine when using a standard Sun JDK and the build process is handled with the Ant system.
Building the Java SP