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
algorithm
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
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.
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
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
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
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
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
algorithm 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
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
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
Hi,
On Tuesday 24 June 2008 13:53, Jean-Sébastien Guay wrote:
OK, that clears that up. Ignore my question about CMake adding
/Dsomething 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
Hi,
On Tuesday 24 June 2008 13:51, Jean-Sébastien Guay wrote:
No need for algorithm 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
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
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
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
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
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
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
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
-
From: Jean-Sébastien Guay [EMAIL PROTECTED]
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
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
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
2Font.cpp
2..\..\..\..\..\externals\OpenSceneGraph\src\osgText\Font.cpp(477) :
error C2589: '(' : illegal token on right side
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
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
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.
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
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
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
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
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,
29 matches
Mail list logo
