Table of contents:
1. What is SOMELib?
2. How did SOMELib start?
3. What does SOMELib stand for?
4. What are the required programs to compile SOMELib with?
5. What platforms does SOMELib compile on?
6. How do I get SOMELib to compile on my platform?
7. I created a SOME Object but it will not compile on platform XYZ.
8. Why does SOMELib use the STL?
9. Is SOMELib an object model/framework?
10. Why doesn't SOMELib enforce the use of UUID's?
11. Why is feature XYZ not in SOMELib?
12. Will feature XYZ be part of SOMELib in the future?
13. I would like to help but I am not a programmer. Can I?
SOMELib is a simple C++ runtime object loader that works on multiple platforms.
SOMELib was started by John Palmieri (aka Quinticent) in 1998 under the name SOMLib as an experiment and plugin system for his bigger Snaglepuss project. It was released under version 0.3 and later 0.4, which added threading. The project was then abandoned for various reasons. In the summer of 2000 Quinticent was contacted by Thomas Matelich on the possibility of a Windows port of SOMLib. At the same time Karl Matthew Baeuerlin sent over a totally rewritten version of SOMLib. At that point SOMLib's name was changed to SOMELib and set up on SourceForge. Tom was then appointed maintainer and proceeded to merge Quinticent's and Karl's codebase while getting it to compile for Windows. Tom and Quinticent still work hard on the project.
SOMELib was originally called SOMLib, which stood for the "Simple Object Model Library". It was later found out that this conflicted with IBM's Corba based "System Object Model" and was a point of confusion for many people. So after the code was changed and placed on SourceForge the name was changed to SOMELib, which is how it was originally pronounced. It really has no meaning now other than being some library. It just seemed right since SOMELib is library that loads other libraries.
What are the required programs to compile SOMELib with?
g++ with STL support and gmake are required on Unix systems. Visual C++ is required for Windows systems. It is recommended that the same version compiler be used to compile SOMELib and programs that use SOMELib as calling conventions across different compiler versions may vary. I believe this is stabilizing but compiling across different compiler versions has not been tested yet.
What platforms does SOMELib compile on?
Right now SOMELib has been tested and works under Linux Kernel 2.2, FreeBSD and Windows. HPUX is in the works. Other systems which use .so's and support libdl should compile fine with minor tweaks to the configure.in script. For some reason the Solaris systems at my school would compile the source code fine but would spew pages worth of linker errors when the object files were linked. This could be a result of missconfiguration of the linker or a bug in gcc. In any case if someone can get it running on Solaris please send patches.
How do I get SOMELib to compile on my platform?
For SOMELib to work on multiple platforms it needs to be configured correctly. This is done by the configure script which detects the platform you are compiling under and configures the makefiles to compile correctly. Unfortunately we do not have the resources to test every platform out there. If your platform supports .so loadable libraries then all that is needed is a small change to the configure.in script. If this is the case simply e-mail one of the maintainers with a description of the platform you are compiling under and include the output that your received when you ran the configure script.
If your system is not Window or Unix then SOMELib needs to be ported to your platform. This is a bit more involved but not very hard for an experienced programmer. Only a few files need to be changed. In the future there will be a porting guide available to all those who wish to port SOMELib to new platforms.
I created a SOME Object but it will not compile on platform XYZ.
While SOMELib is a cross-platform library, user created objects - affectionately called SOME Objects - are not restricted by SOMELib at all and are free to use platform dependent code. It is strongly suggested that you stick to ANSI and POSIX programming practices for maximum portability. Creating cross platform C++ code is beyond the scope of this document but it can be done as evidenced by SOMELib itself.
SOMELib has been criticized for using the STL. While I will admit there are some problems with the STL, specifically in generated code size, the use of the STL has allowed SOMELib to progress at lightning speed while keeping major bugs at a standstill. Another benefit of the STL is the reduced learning curve for C++ programmers. Most C++ programmers are familiar with the workings of STL lists, maps and iterators so the use of the STL does not enforce any new interfaces on them. Now that SOMELib has entered the Beta phased the STL may be phased out and replaced with a work alike version that works better under dynamic systems with less of a memory footprint. It all depends on what people who use the library want.
Is SOMELib an object model/framework?
The first release of SOMLib was working towards being an object model by enforcing base classes and parameter restrictions. When the code was redone we felt that this way of thinking complicated the system too much. There are already good systems out there that allow you to reuse components compiled for different applications by enforcing a standard framework. XPCOM, Corba, Bonobo and KParts come to mind. SOMELib wanted to be a simple way to add plugins to your C++ code. It is an extension to C's libdl on Unix systems. The only restriction we impose is what C++ imposes itself. If you wanted to you could build a framework above SOMELib that allows you to share classes between applications but SOMELib does not enforce this. In this way SOMELib is very flexible and extensible. It is so flexible that existing C++ classes can easily be converted to SOME Objects.
Why doesn't SOMELib enforce the use of UUID's?
Same as above. While UUID's are a great way to avoid name clashes we did not want to force people to use them. Instead we use a catalog system in which each object is categorized by an unlimited number of attributes. If the programmer wishes, one of these attributes can be a UUID. Again this is not enforced.
Why is feature XYZ not in SOMELib?
Many features can be built on top of SOMELib and do not need to be in the core. There are also a number of features that we simply did not think of. If you have and idea please join the mailing list on our SourceForge page and we can discuss your ideas.
Will feature XYZ be part of SOMELib in the future?
I can't say. SOMELib is constantly evolving. If you think you can help out grab the CVS tree and add the features you would like to see implemented then send us the patches. We could use all the help we can get. Also join the mailing list so we can discuss the new features.
I would like to help but I am not a programmer. Can I?
Yes. We need people to help with maintaining the builds, updating the web page and keeping us all up to date. Contact one of the maintainers as any help you can give will be greatly valued.