Hi Eric, On 5/2/07, E. Wing <[EMAIL PROTECTED]> wrote:
So I wish you could have at least humored me and at least experimented with the unification script
Unification scripts don't solve the basic problems of the OSG having external dependencies. I believe its simply a bad idea, and I always have. I submitted yesterday so we could discuss
the tradeoffs before doing all this. I put a lot of design work and effort into it and I'm not convinced that what you just did was the least painful approach. In fact, I'm worried it might be more painful because it ignores a bunch of the details I had already considered in the design.
I'm sorry that integration makes the whole unification script work redundent. This is what I've been trying to do with the OSG in general, make things simpler, make redundant extra complexity. Now, this isn't to say that integration won't have its own issues...
So first, we can't remove the FindOpenThreads stuff. There are legitimate reasons why a user may want or need to use a prebuilt external version. The user may have modified the source or needed to modify the build options for OpenThreads in such a way that it is difficult to do here.
I'm pulling in OpenThreads SVN trunk, so any changes to it will be reflected on the OSG side. If users modify the source code OpenThreads then this should be published and ideally placed into OpenThreads SVN, otherwise they can just stick with their own local mods to the OpenSceneGraph checkout. Furthermore, I this new approach currently loses
functionality that should be considered mandatory.
What functionality is lost? Supporting an external OpenThreads is the only item I see as lost, but this is rather a moot point, as the SVN version of the OSG needs the SVN version of OpenThreads, so an external OpenThreads won't be sufficient anyway. So some specifics. In OS X Tiger, the Unix layer is 64-bit clean, but
other layers are not. We can build and use OpenThreads as 64-bit, but not the stuff in OSG. In using the OSG build settings, we effectively clobber the 64-bit settings by needing to force it off.
If you build OSG in 32 bit then a OpenThreads 64bit is not particularly useful. Another example, which you kind of already address is the USE_SPROC
option. You had to push down the code into a lower level script which may be less intuitive. The nice thing about the Unification script is you inherit everything so you don't lose features like this and have to do things like this. Also, there is currently a critical bug. Remember to support Sproc in OpenThreads, we had to rewrite and override the built-in FindThreads.cmake script. This script is bypassed in this new setup as far as I can tell.
We can move the USE_SPROC make up to the top level for both OpenThreads and OpenSceneGraph. This is just tweaking. And yet another example is Versioning. There are two aspects of
versioning specifically in my mind. There is the versioning of the actual library related to what's in the header files, and there is the aspect of versioning as being discussed on osg-build with respect to using OS level functionality in marking the library binaries. Remember that OpenThreads versioning is separate from OSG versioning. So the first part is syncing the versioning with the headers. In my opinion the cleanest way of doing this is reading the header files directly and use pattern matching for the key variables. This is opposed to writing into the header files to stamp the version which gets really messy or using TRY_COMPILE/TRY_RUN which may get us into trouble with cross-compiling which is an option I want to leave open for the future as there is general interest in the CMake community for such a feature. The second aspect is to stamp the libraries with the correct compatibility version. This may require negotiation with the version information in the headers. To coordinate the two, the easiest and most intuitive thing to do is put this in the root CMakeLists.txt that is above both include/ and src/, but we bypass this root script now. Again, we really shouldn't be adding OpenThreads specific options to the OSG build system or we have to implement them twice and keep them in sync. Again, the unification script doesn't need to worry about this.
I am not going for unification scripts, its messy, complicated and goes against trying to simplify life for the vast majority of OpenScenGraph users. I consider it a bad idea, I won't go anywhere near it, its a complete no started. One single download, one single build is as simple as we can make it, this is where we are at now. So, lets move on to working out how best to work with OpenThreads integrated. If there are any end cases that don't quite work yet then we can tweak them. I have already fixed the install header problem. No doubt there will be other as I've only spent a few hours on integration so far, I can't see any reason why we won't be able to iron out the bumps. Robert.
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
