Hi, On Wednesday 25 June 2008 17:59, Jean-Sébastien Guay wrote: > I think you're mixing things up. There are three different issues here: > > 1. The choice to use Config headers. > 2. The fact that the Atomic header includes windows.h. > 3. The fact that your version of CMake chooses the wrong configuration > and does not generate the Config header. Yep.
> Number 1 is a design choice. The choice is basically between having a > file that defines options that affect the build, and needing to specify > those options as defines in *each* project that uses OSG. I can see why > the choice to have a Config file was taken. Otherwise, you would have to > support people configuring their OSG build one way and then linking to > it in a project where the incorrect define was being used, which would > happen more often than you'd think. Having a Config header ensures that > both the built version of OSG and your project use the same options (as > long as the same Config header is included for both). Yep, thanks! > Number 2 was a mistake (by the person who made the change, but still > unrelated to the choice in number 1), and is being rectified as we > speak. Check the messages from yesterday. *That* is what's breaking the > build on Windows right now. Yep, I took that from two other open source projects I have provided that code for. None of them where that sensitive with including Windows.h. These projects could benefit from inlining the functions directly. osg cannot ... Patch is prepared ... > As for Number 3, I believe that is caused by CMake 2.4.x. This can be > investigated and fixed *after* the windows.h issue is fixed, which is > much more major (as it affects *everyone* building on Windows, > independently of the version of CMake they use). A workaround for you > would be to get CMake 2.6 from cmake.org. Then you would get the right > configuration (interlocked), the Config header would be generated and > used, and you would see the windows.h include problem... At least that's > what I think. :-) That is a bug in the implementation of the configure check. Alternatively an invocation problem with cmake. I need to call cmake with the right output target to make it set up configuration test correct for the msvc8 win64 build for example. > > " > > you don't need anything different than > > before, since the Config headers are installed with your other OSG > > headers. > > " > > Do you have an "out-of-source" configuration or in source? > > I use the "out-of-source" configuration and so the config headers are > > installed in the <build> directory. > > I use an out-of-source build with CMake 2.6, and the Config header is > being generated just fine. But what I was talking about in the line you > quoted above is that OSG headers are including the Config headers. If > you don't do an INSTALL (or make install), then the Config headers are > not together with your other OSG headers. > > Config headers: > OpenSceneGraph/<build>/include/OpenThreads/Config > OpenSceneGraph/<build>/include/osg/Config > > Other headers: > OpenSceneGraph/include/OpenThreads/* > OpenSceneGraph/include/osg/* And installed headers and libs: <prefix>/include/* <prefix>/lib/* ... note: just one single directory to care for. On *NIX often in a prefix so that you do not need to do anything on the compiler command line to make the compiler find that library. > So the other headers won't find #include <OpenThreads/Config> or > #include <osg/Config> unless you add the directories above (in <build>) > to your include file search path. Which was not required before. > > But if you do an INSTALL, you don't have that problem, because the > INSTALL target copies the Config headers to the same place as the other > headers, and so #include <OpenThreads/Config> will work without any > change to your project files. Yep, an install will provide all files together in one directory tree. The build stage is just an intermediate step that I was surprised somebody will use as is. Plenty libraries I know of are only usable when installed. Before you will not have any chance to find the shared or static libraries or includes somewhere deep in the build/source tree. When you execute that intall step, you will not notice any difference between before that change and past that change. Just that difference that you do no longer need to care for keeping defines in sync across probably many libs/apps using osg. And that is a benefit IMO ... > I hope that clears things up. Thanks, for writing! GReetings Mathias -- Dr. Mathias Fröhlich, science + computing ag, Software Solutions Hagellocher Weg 71-75, D-72070 Tuebingen, Germany Phone: +49 7071 9457-268, Fax: +49 7071 9457-511 -- Vorstand/Board of Management: Dr. Bernd Finkbeiner, Dr. Florian Geyer, Dr. Roland Niemeier, Dr. Arno Steitz, Dr. Ingrid Zech Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board: Prof. Dr. Hanns Ruder Sitz/Registered Office: Tuebingen Registergericht/Registration Court: Stuttgart Registernummer/Commercial Register No.: HRB 382196 _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
