Hi, On Tuesday 24 June 2008 13:47, Jean-Sébastien Guay wrote: > Config header: > > The config header is just a way to tell the atomic integer class which > > implementation to use. This is basically due to the lack of an atomic > > type in the c++ standard (which is addressed in the next standard version > > btw). > > From what I see, the Config header only defines a given symbol > depending on the compiler/platform you're on. Couldn't CMake just add a > "/D<something>" to the compiler command line instead of creating a file > for that? Hmm, that is what I wanted to avoid. If you do that, you have to make sure that whenever you make use of osg, you must make sure that you give the same defines than at build time. Remember that these defines change the class layout or the api provided by the headers. Think of a binary distribution of osg. You will not have access to any cmake related files. You need to document what you configured and then carefully take the documented defines and type them exactly into your project configuration. Or think of all those Linux/UNIX people who just install an rpm or debian package that contains headers and libraries.
If you have that in a file that is distributed with the headers, you will make sure that these defines match the binaries you have. Without question, defines which do not change the api or class layout can be just defined at osg build time in the build system on the compiler command line. That does not matter for the user of a library. You may think of that Config file as a 'compiler native way to document which api version was compiled into your library'. If you do in source builds, you will not notice anything different. If you do out of source builds, add the path to the build time includes to the include path and you will get the correct headers for the libs that are in the same build directory. Alternatively, cmake povides an 'install' target on unix builds. I do not know if this is also available in win32. But if this is available, the install step should then provide a complete and self consistent tree of includes and libraries that just match each other without special knowledge about the build environment. > But that still does not address the problems we're seeing related to > Atomic including windows.h everywhere. I'll have a go at fixing that. I see that problem. Appologies for not testing that stuff on windows. I was just too naive to believe that this will just work. And given that I do cross platform development here at work I must have known that better. Sorry! I believe that I will provide something that will use inline versions of that atomic functions if possible but will make some cpp file implementation if this does not make sense like in the win32 case ... Robert, ok? That will eliminate some parts of the runtime benefits for some targets but there are still many advantages there. I expect that still to be much faster than using mutexes. I guess that this will be ready about tomorrow. I hope that you can live with that until then ... 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
