Re: [osg-users] Windows build is broken
Hi Mike, Paul, I see the same, though this exact same code compiled OK in the 2.5.2 dev release, so I imagine this new issue is caused by a change to the cmake config files. Strange, I'm not seeing any of this (SVN rev 8492, Windows Vista, CMake 2.6, VS 8). Everything builds fine for me. I'll try a fresh build just to make sure I don't have some leftover state that's making things work (which would be a first, normally it's the opposite...) Could you guys do the same, at least that will eliminate some variables. (delete your build directory if you're using an out-of-source build, or at least delete your CMakeCache.txt file, then re-run CMake and try to rebuild) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi Paul, Hm. The OpenThreads\Config header (in this directory) #defines a symbol that results in the inclusion of windows.h within OT's "Atomic" header. I wonder if this could be why std::max is giving us grief? Hmm, I think you're right, there should probably be the classic #define NOMINMAX or whatever there... But at this point I'm rebuilding from scratch (osg done, halfway through osgDB and osgUtil) and am not getting the errors you're getting... What's your setup? (CMake version, compiler, etc.) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi Paul, But at this point I'm rebuilding from scratch (osg done, halfway through osgDB and osgUtil) and am not getting the errors you're getting... Spoke too soon. I'm now getting the errors you and Mike spoke of. I'll look into it. (note that I'm not involved with the Config headers change, but I'm just curious...) J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
> > But at this point I'm rebuilding from scratch (osg done, halfway > > through osgDB and osgUtil) and am not getting the errors you're > > getting... > > Spoke too soon. I'm now getting the errors you and Mike spoke > of. I'll look into it. (note that I'm not involved with the > Config headers change, but I'm just curious...) Thanks for taking a look. At some point I'd like to understand this change and why it was required, but right now I don't feel like wading through ~40 emails to understand it. Easiest/fastest way to repro this problem from a clean tree: try to compile osgText\Font.cpp. (FYI, I have cmake 2.6, VS8, winxp. I haven't tried this on Mac OSX yet, but this issue smells like it's Windows-only.) Are there now restrictions on where the build directory can live? I usually have a "bld" directory as a sibling to "src", "include", etc. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi Paul, Thanks for taking a look. At some point I'd like to understand this change and why it was required, but right now I don't feel like wading through ~40 emails to understand it. I actually followed the e-mails related to this and *still* don't understand why a Config header is required! ;) Are there now restrictions on where the build directory can live? I usually have a "bld" directory as a sibling to "src", "include", etc. I have the same convention (my directory is called "build" but then I'm a verbose person as you know :-) ). I doubt any restriction of the sort exists. The problem is probably something else. I'll check it out. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi again, The problem is probably something else. I'll check it out. I'm well on my way on a new build, which seems to be going well. I just changed the Atomic header to set the defines which are commonly set to avoid windows.h polluting the namespace with lots of junk, i.e.: #if defined(_OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED) # ifndef _WIN32_WINNT # define _WIN32_WINNT 0x0400 # endif # ifndef WIN32_LEAN_AND_MEAN # define WIN32_LEAN_AND_MEAN # endif # ifndef NOMINMAX # define NOMINMAX # endif # include // ... And it seems to be going well. These are things which need to be defined the first time windows.h is included (which was somewhere else before, but now it's in OT/include/Atomic), otherwise the right things don't get included (or the wrong things get included). windows.h is a monolithic header, and it has lots of confusing options as to what gets included in which conditions... To prevent such things from happening again (or at least make it harder), perhaps we could make a header called "Win32" or something in OpenThreads, which would be included whenever windows.h is needed in both OSG and OT, and which would define the right options. That way we wouldn't have windows.h included in lots of places and with different options each time... For reference, there are currently about 22 places in the OSG sources where windows.h is included - some in core projects, some in examples, some in plugins... Anyways, I'll chime in when the build finishes. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi again Paul, I'm well on my way on a new build, which seems to be going well. Nope, there are still some problems. Seems some plugins (lwo, net and jpeg) need the whole windows.h (without WIN32_LEAN_AND_MEAN). I'm trying a build with that. Unfortunately that will bring lots and lots of stuff into the main namespace, but I don't see a way around it. The base of the problem seems to be including windows.h in such a central place. I need to figure out how to include it to make all the OSG sources happy - because of the include guards, it won't get included in other places, even if the options change. I'll let you know how it goes. On a related note, I got an error in osgthirdpersonview: "near" and "far" are defined by windows.h (or a header included from windows.h), and since that's being included everywhere now, there was a clash with the variables of the same name in that example. Just renaming them fixed it. I can submit that or you can decide on a suitable name and submit it. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi again, I'll let you know how it goes. Still a no go. I'm turning in for the night, but I'll try something else tomorrow. I'm considering splitting Atomic into a header and a .cpp file, so that windows.h can be included only in the implementation and not the header. That would fix it, since the problems I'm seeing are caused by the fact that windows.h is being included at the very top level of the include chain. Not sure if that has any other implications though. Thoughts? J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi,
On Tuesday 24 June 2008 07:02, Jean-Sébastien Guay wrote:
> > I'll let you know how it goes.
>
> Still a no go. I'm turning in for the night, but I'll try something else
> tomorrow.
>
> I'm considering splitting Atomic into a header and a .cpp file, so that
> windows.h can be included only in the implementation and not the header.
> That would fix it, since the problems I'm seeing are caused by the fact
> that windows.h is being included at the very top level of the include
> chain. Not sure if that has any other implications though. Thoughts?
Well, I try to summarize that somehow:
osg uses reference counting in many places.
These reference counts need to be thread safe in many cases. The most
important ones aries in the multithreaded viewer code paths I guess. So
everybody using a threaded viewer will benefit from that.
You have two options to make that thread safe.
* Either use a mutex that is held during modification (Relatively slow,
involves even a system call per lock and one per unlock on many platforms).
* Use a single assembler instruction that guarantees that the modification
happens atomically (Way faster).
Modifying that reference count happens very often. It happens that often that
you observe execution speed improovements when you optimize that code path.
The best improovements will happen when you inline that reference counting
stuff completely in the calling code. That also enables compiler
optimizations so that in some cases the count modifications can be eliminated
completely.
Therefore the Atomic stuff, which is inlined into code that is compiled even
in code that just calls osg (more exact: that uses osg::Referenced::
{ref,unref}, that is used from osg::ref_ptr). That means you need to
include the atomic code into basically everything.
Therefore including Windows.h in Atomic.
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).
When you want to inline the fast path of the reference counting stuff, you
need to make sure that you pick up the right atomic increment implementation
in Atomic which should match the one used when compiling osg. Therefore the
Config header.
That's all.
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
Re: [osg-users] Windows build is broken
Hi, On Tuesday 24 June 2008 03:25, Jean-Sébastien Guay wrote: > I actually followed the e-mails related to this and *still* don't > understand why a Config header is required! ;) Well that is somehow orthogonal to the windows.h include. That config header just makes sure, that defines that change the api of some classes or that change the class layout in memory are consistent for one build. This was no problem for osg as such. But when you use osg, you need to make sure that all files that include some osg header have the same defines in your project like you had when compiling osg. Otherwise you might get unresolved symbols in the good case or mysterious crashes in the bad case. This Config header includes those defines that change the api and by defining them in a file that is included at built and installed with the binaries ensure that you get the same defines when you just include osg headers from that build/install directory where you take the libs. You do not need to make sure that you apply the same defines that you used when compiling osg. You just get that for free. IMO this is an advantage. 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
Re: [osg-users] Windows build is broken
Hello Mathias, Thanks a lot for the explanation of the Atomic stuff. Regarding the 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" to the compiler command line instead of creating a file for that? 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. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi Mathias, Probably we should either * define nominmax on win32 in any case or * change the code not to use variables called min or max and include which should provide std::min and std::max and makes msvc 8 indeed compile the code (does this also work for other msvc's??). No need for either, we have osg::maximum and osg::minimum. But that's not the root of the problem. windows.h defines so much junk that it should only be included in very specific cases, not everywhere. But Atomic, since it's a requirement for thread-safe ref counting and is only a header, is included everywhere and includes windows.h. Splitting Atomic into a header and an implementation file would fix that. Only the .cpp would include windows.h. As I said, I'll check that out. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hello Mathias, I actually followed the e-mails related to this and *still* don't understand why a Config header is required! ;) Well that is somehow orthogonal to the windows.h include. Yes of course, but since both (the Atomic header and the Config header) came in because of the same change (atomic ref counting) they're still related. This Config header includes those defines that change the api and by defining them in a file that is included at built and installed with the binaries ensure that you get the same defines when you just include osg headers from that build/install directory where you take the libs. OK, that clears that up. Ignore my question about CMake adding "/D" to the build command line. You're right, in that case we would need to make sure every client app had the same define, which would be a chore. A Config header is better, I agree. Thanks for explaining. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
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" 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
Re: [osg-users] Windows build is broken
Hi, On Tuesday 24 June 2008 13:53, Jean-Sébastien Guay wrote: > OK, that clears that up. Ignore my question about CMake adding > "/D" to the build command line. You're right, in that case we > would need to make sure every client app had the same define, which > would be a chore. A Config header is better, I agree. > > Thanks for explaining. Already answered, not a problem :) 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
Re: [osg-users] Windows build is broken
Hi, On Tuesday 24 June 2008 13:51, Jean-Sébastien Guay wrote: > No need for either, we have osg::maximum and osg::minimum. > But that's not the root of the problem. windows.h defines so much junk > that it should only be included in very specific cases, not everywhere. > But Atomic, since it's a requirement for thread-safe ref counting and is > only a header, is included everywhere and includes windows.h. > > Splitting Atomic into a header and an implementation file would fix > that. Only the .cpp would include windows.h. As I said, I'll check that > out. Will you or should I? I have done the offending change so, I can make sure that it works again? I just want to avoid duplicate work. 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
Re: [osg-users] Windows build is broken
Hello Mathias, Alternatively, cmake povides an 'install' target on unix builds. I do not know if this is also available in win32. Yes, and I always use it, and it works (copies the Config header). So no problem there. 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! Hehe, classic mistake! :-) 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 ... I think if you declare both the declaration and implementation of a method inline, the compiler will take that as a hint that it should be inlined if possible... But yes, windows.h should only be included in a .cpp file in the case of a header like Atomic that is included everywhere... Robert, ok? Robert is not checking his mails until Thursday. Since this currently prevents building on Windows, I would say go ahead. I guess that this will be ready about tomorrow. I hope that you can live with that until then ... OK, I was having a go at doing it, but if you want to go ahead, you're more familiar with it than I am. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi Mathias, Will you or should I? I have done the offending change so, I can make sure that it works again? I just want to avoid duplicate work. Yes, go ahead. I had started, but it's more logical that you do it. Send the changed files on the list when you're done and I'll check them out and try a build (tomorrow morning probably, I'll be offline for the rest of today). Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi J-S > -Original Message- > From: [EMAIL PROTECTED] [mailto:osg-users- > [EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay > Sent: Monday, June 23, 2008 11:03 PM > To: OpenSceneGraph Users > Subject: Re: [osg-users] Windows build is broken ... > On a related note, I got an error in osgthirdpersonview: "near" and > "far" are defined by windows.h (or a header included from windows.h), > and since that's being included everywhere now, there was a clash with > the variables of the same name in that example. Just renaming them > fixed > it. I can submit that or you can decide on a suitable name and submit > it. I believe the simple tokens "near" and "far" are keywords in the VS compiler (a legacy of the distinction between the near and far pointers of the x86 architecture way way back when) To avoid the subtle (and not always informative) error messages, I always use "znear" and "zfar". -- mew ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
" Yes, and I always use it, and it works (copies the Config header). So no problem there. " Given that we are building an out-of-source solution as of build 8483: It does indeed copy the config file to the build directory for me as well, but for VS 7.1 using cmake 2.4.8 it fails to identify using Interlocked, and the config files revert to a single threaded environment. This is minor, but can get annoying if something wants to rebuild. Aside from this only OpenThreads and OSG include the build path... all projects dependant on these do not, and will give error that they cannot find the config file. Ideally the cmake scripts of these projects should also include the build path. I'm going to hold off on getting the latest until Mathias has a chance to checkin some fixes with windows.h - Original Message - From: Jean-Sébastien Guay To: OpenSceneGraph Users Sent: Tuesday, June 24, 2008 7:25 AM Subject: Re: [osg-users] Windows build is broken Hello Mathias, > Alternatively, cmake povides an 'install' target on unix builds. I do not know > if this is also available in win32. Yes, and I always use it, and it works (copies the Config header). So no problem there. > 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! Hehe, classic mistake! :-) > 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 ... I think if you declare both the declaration and implementation of a method inline, the compiler will take that as a hint that it should be inlined if possible... But yes, windows.h should only be included in a .cpp file in the case of a header like Atomic that is included everywhere... > Robert, ok? Robert is not checking his mails until Thursday. Since this currently prevents building on Windows, I would say go ahead. > I guess that this will be ready about tomorrow. I hope that you can live with > that until then ... OK, I was having a go at doing it, but if you want to go ahead, you're more familiar with it than I am. Thanks, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi Mike, I believe the simple tokens "near" and "far" are keywords in the VS compiler (a legacy of the distinction between the near and far pointers of the x86 architecture way way back when) They're not keywords, they're #defined in a header that's included when you include windows.h. Since osgthirdpersonview did not include windows.h before, there was no problem. Now, as it stands, Atomic is being included everywhere, and includes windows.h, hence the problem. But the rest of your analysis is right. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi James, I'm going to hold off on getting the latest until Mathias has a chance to checkin some fixes with windows.h Probably a good idea, then we can check if there are any other outstanding issues. BTW, did you set your e-mail message's background to black or am I seeing a bug in my client or yours? Your message was black text on black background. :-( J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
> On a related note, I got an error in osgthirdpersonview: > "near" and "far" are defined by windows.h (or a header > included from windows.h), and since that's being included > everywhere now, there was a clash with the variables of the > same name in that example. Just renaming them fixed it. I can > submit that or you can decide on a suitable name and submit it. "near" and "far" are not reserved words in standard C++. The variable names should remain as-is. Instead, I'd propose that _no_ OSG header should _ever_ #include _any_ platform-specific header file (such as windows.h). Platform-specific headers should be #included in .cpp files only. Implementation-hiding is something that C++ is supposed to be good at, but the author of this recent change to the OT Atomic header failed to consider this. This is broken and needs to be fixed. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Hi Paul, "near" and "far" are not reserved words in standard C++. The variable names should remain as-is. Sometimes you need to pick your battles, and I like Mike have learned to avoid using near and far as variable names, to avoid problems. But what you say is true, and if the root problem is fixed, then they could stay as they are for all I care. ... but the author of this recent change to the OT Atomic header failed to consider this. This is broken and needs to be fixed. It's in the process of being rectified. I don't think Mathias voluntarily broke the build on Windows... He didn't test thoroughly on Windows, which is a mistake we all make. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
> It's in the process of being rectified. Yes, I see now I should've read the whole thread before posting. Looks like you and Mathias are on top of the issue. Thanks. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken
Sorry about the black on black, sometimes Outlook express likes to enter a black background when I switch into html. I try to keep plain text to avoid issue... my black contrast environment helps reduce the amount of light emitting from the monitors. James Killian - Original Message - From: "Jean-Sébastien Guay" <[EMAIL PROTECTED]> To: "OpenSceneGraph Users" Sent: Tuesday, June 24, 2008 3:54 PM Subject: Re: [osg-users] Windows build is broken Hi James, I'm going to hold off on getting the latest until Mathias has a chance to checkin some fixes with windows.h Probably a good idea, then we can check if there are any other outstanding issues. BTW, did you set your e-mail message's background to black or am I seeing a bug in my client or yours? Your message was black text on black background. :-( J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken (was: RE: Please test SVNofOpenSceneGraph in pre for2.5.3dev release)
> The only significant compile option differences between 2.5.2 > (which works) and svn head (which fails) is that the svn head > contains an additional /I option not present in 2.5.2: >/I "C:\OSGDev\OSG\bld\include" > > (that is, essentially, a new "include" subdirectory within > the build directory, which doesn't exist in 2.5.2.) Hm. The OpenThreads\Config header (in this directory) #defines a symbol that results in the inclusion of windows.h within OT's "Atomic" header. I wonder if this could be why std::max is giving us grief? I see there has been great discussion about "API config in single header", so I'll let those of you involved in this decision work it out... -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken (was: RE: Please test SVNofOpenSceneGraph in pre for2.5.3dev release)
On Tuesday 24 June 2008 01:34, Paul Martz wrote: > > The only significant compile option differences between 2.5.2 > > (which works) and svn head (which fails) is that the svn head > > contains an additional /I option not present in 2.5.2: > >/I "C:\OSGDev\OSG\bld\include" > > > > (that is, essentially, a new "include" subdirectory within > > the build directory, which doesn't exist in 2.5.2.) > > Hm. The OpenThreads\Config header (in this directory) #defines a symbol > that results in the inclusion of windows.h within OT's "Atomic" header. I > wonder if this could be why std::max is giving us grief? Hmm, that pulls windows.h yes. These are that annoying min and max macros defined there. As documented by msdn one should include windows.h when using that functions/intrinsics. So there seems to be a requirement for that. The build system defines the nominmax define only for msys and cygwin. Probably we should either * define nominmax on win32 in any case or * change the code not to use variables called min or max and include which should provide std::min and std::max and makes msvc 8 indeed compile the code (does this also work for other msvc's??). Which one Robert? 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
Re: [osg-users] Windows build is broken (was: RE: Please test SVNofOpenSceneGraph in pre for2.5.3dev release)
On Tue, Jun 24, 2008 at 8:55 AM, Mathias Fröhlich <[EMAIL PROTECTED]> wrote: > The build system defines the nominmax define only for msys and cygwin. > > Probably we should either > * define nominmax on win32 in any case or > * change the code not to use variables called min or max and include > which should provide std::min and std::max and makes msvc 8 > indeed compile the code (does this also work for other msvc's??). > > Which one Robert? Mathias is this now fixed with the latest changes from you? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken (was: RE: Please test SVNofOpenSceneGraph in pre for2.5.3dev release)
Robert, On Thursday 26 June 2008 12:18, Robert Osfield wrote: > Mathias is this now fixed with the latest changes from you? It compiles again, yes. Pulling Windows.h did break it. So forget that. Anyway, the no-windows-h tarball was not fully integrated. At least I can see still a diff to the tree where I extrected the change. The atomic implementation file is missing in some cases. 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
Re: [osg-users] Windows build is broken (was: RE: Please test SVNofOpenSceneGraph in pre for2.5.3dev release)
Hi Mathias, Which specific submissions/file is missing? Robert. On Thu, Jun 26, 2008 at 12:27 PM, Mathias Fröhlich <[EMAIL PROTECTED]> wrote: > > Robert, > > On Thursday 26 June 2008 12:18, Robert Osfield wrote: >> Mathias is this now fixed with the latest changes from you? > It compiles again, yes. > Pulling Windows.h did break it. > So forget that. > > Anyway, the no-windows-h tarball was not fully integrated. At least I can see > still a diff to the tree where I extrected the change. The atomic > implementation file is missing in some cases. > > 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 > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken (was: RE: Please test SVNofOpenSceneGraph in pre for2.5.3dev release)
Hi Robert, On Thursday 26 June 2008 14:29, Robert Osfield wrote: > Which specific submissions/file is missing? May by I have forgotten them, I will send ... src/OpenThreads/win32/CMakeLists.txt src/OpenThreads/sproc/CMakeLists.txt 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
Re: [osg-users] Windows build is broken (was: RE: Please test SVNofOpenSceneGraph in pre for2.5.3dev release)
On Thu, Jun 26, 2008 at 4:01 PM, Mathias Fröhlich <[EMAIL PROTECTED]> wrote: > > Hi Robert, > > On Thursday 26 June 2008 14:29, Robert Osfield wrote: >> Which specific submissions/file is missing? > May by I have forgotten them, I will send ... > > src/OpenThreads/win32/CMakeLists.txt > src/OpenThreads/sproc/CMakeLists.txt Sorry about this, changes now checked in. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows build is broken (was: RE: Please test SVN ofOpenSceneGraph in pre for2.5.3dev release)
The only significant compile option differences between 2.5.2 (which works)
and svn head (which fails) is that the svn head contains an additional /I
option not present in 2.5.2:
/I "C:\OSGDev\OSG\bld\include"
(that is, essentially, a new "include" subdirectory within the build
directory, which doesn't exist in 2.5.2.)
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Paul Martz
> Sent: Monday, June 23, 2008 4:51 PM
> To: 'OpenSceneGraph Users'
> Subject: [osg-users] Windows build is broken (was: RE: Please
> test SVN ofOpenSceneGraph in pre for2.5.3dev release)
>
> I see the same, though this exact same code compiled OK in
> the 2.5.2 dev release, so I imagine this new issue is caused
> by a change to the cmake config files.
>-Paul
>
>
> > 2>Font.cpp
> >
> 2>..\..\..\..\..\externals\OpenSceneGraph\src\osgText\Font.cpp(477) :
> > error C2589: '(' : illegal token on right side of '::'
> >
> 2>..\..\..\..\..\externals\OpenSceneGraph\src\osgText\Font.cpp(477) :
> > error C2059: syntax error : '::'
> >
> > 90>..\..\..\..\..\..\externals\OpenSceneGraph\src\osgPlugins\O
> penFlight\
> > 90>expGeometryRecords.cpp(878)
> > : warning C4003: not enough actual parameters for macro 'max'
> >
> >
> > 4>..\..\..\..\..\externals\OpenSceneGraph\src\osgViewer\Graphi
> csWindowWi
> > 4>n32.cpp(2139)
> > : error C2065: 'WM_MOUSEWHEEL' : undeclared identifier
> > 4>..\..\..\..\..\externals\OpenSceneGraph\src\osgViewer\Graphi
> csWindowWi
> > 4>n32.cpp(2139)
> > : error C2051: case expression not constant
> > 4>..\..\..\..\..\externals\OpenSceneGraph\src\osgViewer\Graphi
> csWindowWi
> > 4>n32.cpp(2142)
> > : error C3861: 'GET_WHEEL_DELTA_WPARAM': identifier not found
> >
> > 86>..\..\..\..\..\..\externals\OpenSceneGraph\src\osgPlugins\s
> hp\ESRISha
> > 86>pe.cpp(169)
> > : warning C4003: not enough actual parameters for macro 'min'
> >
> > 86>..\..\..\..\..\..\externals\OpenSceneGraph\src\osgPlugins\s
> hp\ESRISha
> > 86>pe.cpp(169)
> > : error C2059: syntax error : ')'
> >
> > 91>..\..\..\..\..\..\externals\OpenSceneGraph\src\osgPlugins\l
> wo\Unit.cp
> > 91>p(25)
> > : error C2872: 'Polygon' : ambiguous symbol
> > 91>could be 'C:\Program Files\Microsoft Visual Studio
> > 8\VC\PlatformSDK\include\wingdi.h(4002) : BOOL
> Polygon(HDC,const POINT
> > *,int)'
> > 91>or
> > 91>
> > 'd:\mew\mew_trees\osgbuild_trunk\externals\openscenegraph\src\osgplu
> > 91> gins\lwo\Polygon.h(24)
> > : lwosg::Polygon'
> >
> > 105>..\..\..\..\..\externals\OpenSceneGraph\examples\osgthirdp
> ersonview\
> > 105>osgthirdpersonview.cpp(68)
> > : error C2513: 'const double' : no variable declared before '='
> >
> > 105>..\..\..\..\..\externals\OpenSceneGraph\examples\osgthirdp
> ersonview\
> > 105>osgthirdpersonview.cpp(72)
> > : error C2100: illegal indirection
> >
> >
> >
> >
> > On Mon, Jun 23, 2008 at 5:05 PM, Paul Martz
> <[EMAIL PROTECTED]>
> > wrote:
> > > Hi Robert -- I just returned from a vacation and am encountering
> > > multiple build failures. I haven't waded through all the
> osg-users
> > > emails yet, but from your post below, it doesn't sound
> like you're
> > > aware of the issues. Many are STL issues under VS2005 (use of
> > > std::max, for example, instead of osg::maximum). I can post
> > an exhaustive list if you need it.
> > > -Paul
> > >
> > >
> > >> -Original Message-
> > >> From: [EMAIL PROTECTED]
> > >> [mailto:[EMAIL PROTECTED] On Behalf Of
> > >> Robert Osfield
> > >> Sent: Monday, June 23, 2008 12:59 PM
> > >> To: OpenSceneGraph Users
> > >> Subject: Re: [osg-users] Please test SVN of OpenSceneGraph
> > in pre for
> > >> 2.5.3dev release
> > >>
> > >> Hi All,
> > >>
> > >> There have been too many build changes, and not enough testing
> > >> feedback for me to go with a dev release with any
> > confidence so I'll
> > >> not do one today. I'm away on a trip Tuesday and
> > Wednesday, when I
> > >> get back online on Thursday I could possible make
> > OSG-2.5.3 then, so
> > >> you have a few more days testing to do.
> > >>
> > >> If you have fixes you'd like merged before 2.5.3 (i.e.
> > build fixes),
> > >> could you send them into osg-users so others can tests
> > them prior to
> > >> my return.
> > >>
> > >> Cheers,
> > >> Robert.
> > >> ___
> > >> osg-users mailing list
> > >> osg-users@lists.openscenegraph.org
> > >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
> > > negraph.org
> > >
> > > ___
> > > osg-users mailing list
> > > osg-users@lists.openscenegraph.org
> > >
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
> > > org
> > >
> >
> >
> >
> > --
> > Mike Weiblen -- Austin Texas USA -- http://mew.cx/
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/lis
