UOX has consistently migrated back and forth on its support of multiple platforms. In almost every case, it has not take the effort to do the "standard" approach of analysis and wrappering, but usually takes a single approach, and force fits other platforms back into it with a series of ifdefs or "forced wrappers".
The changlog reflects the following:
7/29/2004
Note: We need to change references to __unix__ to something more like UOX_PLATFORM != PLATFORM_WINDOWS or UOX_PLATFORM == PLATFORM_LINUX
Some of che's fixes were not fixes (ie commenting out the throws) or improperly done (platform specific decls don't go in uox3.h)
However, no attempt in the code was first done to identify and isolate where the differences are. Again, yet another effort to start a transistion, that one can arguable (to be seen), is incomplete at best, and will require yet more rework to come.
Platform neutrality normally addresses two aspects, compilier and api differences. For the most part, compilier differences are fewer and fewer, as compliancy has become more the norm (scoping, STL , etc).
So what is meant in the above changlog in the attempt to identify platform? In the traditional sense of the word, one is normally referring to the api that is exposed. Should it use berkley sockets or winsock? What time functions are available? Directory services? It also many times referes to the native processor in respect to large or small endian. What is commonly done, is instead of identifying a "platform", the attempt is made to distinguish the services available (true or false). This identification may be based on some prior platform detection, but is yet another case of isolation.
Why is this seperation signification. Lets take the windows platform. Depending on the compilier used (mingw or msvc), some serviecs are different (especially in the time domain).
The second class of issues come with include's, and the needed dependencies. However, that is usually only of intersest in the wrappered fucntions/classes, that are having to support the differenct services (but not in all cases).
No matter how this is handled, the goal is to minize this throughout the code, and do this via generation of class/functions that mase some differences from the rest of the programming project members. An attempt I suppose of this is the uoxlinux.h file, although that was done after the fact, trying to map linux calls into windows aspects. Versus identifiying, writing a function/class that will support the various services for the function, and then inside that function, handle the differences.
Ok, having gone all through this, lets now examine what got accomplished by this latest UOX_PLATORM attempt. Does it distinguish the concept of services that may vary , even if on the same paltform? Again, examples could be time, and endian (linux platform, but if on PPC, a different endian then if on x86). So in that respect if falls short. And by changing that first (versus first identifying and isolationg the service areas where the changesw are noted), one has the potential for more UOX_PLATFORM areas then needed.
What exactly got gained from this additional change, versus the current limited __unix__ is not clear, but hopefully it is clear that the change by itself isn't true answer to the solution. Yet it was additional time and effort spent, plus debugging effort, that will get to be all revisited again.
I would offer, that it first may be prudent to identify what is the goal to be accomplished, how said approach is an attempt to reach that goal, and then discuss the limitations and advantages of the various implementations.
Granted I have a limited understanding of the final goal, but if an expandable approach to platform neutrality, from what I have seen, this implementation is marginally better then what was there before.
Platform neutrality
Thats the problem I had on Solaris. The _UNIX_ preproc. was set in such a way that it was either on a unix platform or not. Then we were trying to set it in such a way we could configure unix and linux to build within the same preproc. but that didn't work, I think the end conclusion was to make a _linux_, _unix_ and _win32_ heh. Anyway the services is the thing you need and seems to be what most unix apps do nowadays as each system is different. I have no experience in doing such configuration files for specifics - I'd imagine it would be daunting enough to do this unless you knew the code base fairly well to insert and manage the inclusions. I believe the GNU has some guidelines on doing this perhaps. I'm unfamiliar with the autoconf/make tools however as I've never used them before. Perhaps che knows how to and is willing, he seems pretty knowledgable in that area.
well, a __linux__, win32, etc is not the way to go. when __unix__ was introduced, it was a simplification, since it was known at that time, the main goal was windows (msvc) and linux (x86).
I personally wouldn't worry about solaris at this time, as you then have endian and 64 bit issues as well. But going to a service concept, and isolation of differences, really isn't that daunting, for servers like uox don't use that many services that are that different. But if you don't isolate first, and try to "ifdef" in the code, yea, it can be.
My point was, UOX_Platoform isn't a substantial set above what was there all ready.
I personally wouldn't worry about solaris at this time, as you then have endian and 64 bit issues as well. But going to a service concept, and isolation of differences, really isn't that daunting, for servers like uox don't use that many services that are that different. But if you don't isolate first, and try to "ifdef" in the code, yea, it can be.
My point was, UOX_Platoform isn't a substantial set above what was there all ready.