Re: [osg-users] build errors with 2.8.1

[Eric Sokolowsky]

Jason Daly wrote:
> Eric Sokolowsky wrote:
>> John and everyone,
>>
>> I realize I'm getting into this discussion very late (I've been pretty
>> absent from OSG development lately). We also use Centos (currently at
>> 5.2), and the older package versions is a problem for us as well. I have
>> taken it upon myself to make RPMs of several newer packages we require.
>> I can provide .spec files for those who are interested. Here are some of
>> the newer packages I have made (or packages not included in the distro):
>>
>> flex-2.5.35
>> Inventor-2.1.5
>> fltk-1.1.9
>> xxdiff-3.2
>> cmake-2.6.4
>>   
> 
> A couple of those are available at ATrpms (http://atrpms.net/dist/el5/)
> already.  Just mentioning it in case you didn't know (might save you
> some work in the future)

I've avoided ATrpms lately, because some of the packages there didn't
seem to work (and conflicted with other packages we were using).
RPMforge packages, on the other hand, seem to work well for us.

The packages I mentioned above are easy enough to build that the spec
file is really simple, so it really wasn't that much work.

> 
> I also recently discovered the EPEL repository that is run by the Fedora
> project. This one is even nicer because it integrates seamlessly with
> yum (https://fedoraproject.org/wiki/EPEL).

I'll have to look at that one; it sounds interesting.

Thanks!

-Eric
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Jason Daly]

Eric Sokolowsky wrote:

John and everyone,

I realize I'm getting into this discussion very late (I've been pretty
absent from OSG development lately). We also use Centos (currently at
5.2), and the older package versions is a problem for us as well. I have
taken it upon myself to make RPMs of several newer packages we require.
I can provide .spec files for those who are interested. Here are some of
the newer packages I have made (or packages not included in the distro):

flex-2.5.35
Inventor-2.1.5
fltk-1.1.9
xxdiff-3.2
cmake-2.6.4
  


A couple of those are available at ATrpms (http://atrpms.net/dist/el5/) 
already.  Just mentioning it in case you didn't know (might save you 
some work in the future)


I also recently discovered the EPEL repository that is run by the Fedora 
project. This one is even nicer because it integrates seamlessly with 
yum (https://fedoraproject.org/wiki/EPEL).


--"J"


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Eric Sokolowsky]

John Kelso wrote:
> Below is from our sysadmin when I asked him about getting a newer
> version cmake.
> 
> Any comments, anyone?
> 
> Can we really be the only site having this problem?


John and everyone,

I realize I'm getting into this discussion very late (I've been pretty
absent from OSG development lately). We also use Centos (currently at
5.2), and the older package versions is a problem for us as well. I have
taken it upon myself to make RPMs of several newer packages we require.
I can provide .spec files for those who are interested. Here are some of
the newer packages I have made (or packages not included in the distro):

flex-2.5.35
Inventor-2.1.5
fltk-1.1.9
xxdiff-3.2
cmake-2.6.4

-Eric
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Jason Daly]

Robert Osfield wrote:

Um it was mostly a rant...
  


Then you didn't read it.  There were quite a few intelligent points.  
Sure the first part was a rant (I'd call it a counter-rant to yours), 
but the rest were well-formed ideas.




I have already said that if CMake 2.4.5 is possible without causing
problem then I'm happy to see us support CMake 2.4.5.  The key point
is that if you want this support you (as in all users users using this
out of date CMake version) have to be pro-active in making sure that
there aren't any build regressions.
  


And I've said that I will do what I can, but I can't guarantee that I'll 
be able to test each and every time you make a release.  I'm sorry, my 
responsibilities at work come first.  Maybe there really are only two of 
us on this list, and our schedules just don't line up all the time.


This is the nature of OSS.  You can't rely on anyone for certain.  All I 
can say is that I'll do the best I can. 



I do appreciate your contributions, 


Even that little phrase means a lot coming from you.  Thank you.



but that won't mean that I will
shy away from calling out problems when I see them.  The build problem
was minor problem easily dealt with, but the lack of community testing
prior to a release is a big problem here - as fixing problems after
releases is far more expensive, both for me and all those who
contribute to getting releases out the door.
  


I understand that.  I'm just not sure how much more I can do than what 
I've already pledged.


--"J"

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Robert Osfield]

Hi Jason,

On Mon, Jun 8, 2009 at 4:35 PM, Jason Daly wrote:
> And your responses show that you didn't grasp the point of mine.

Um it was mostly a rant...

> You seem to still be under the impression that I expect you to continue
> supporting CMake 2.4.5, no matter what.  Let me be clear here:
>
> *If you don't want to support CMake 2.4.5 anymore, then by all means don't
> support it*

I have already said that if CMake 2.4.5 is possible without causing
problem then I'm happy to see us support CMake 2.4.5.  The key point
is that if you want this support you (as in all users users using this
out of date CMake version) have to be pro-active in making sure that
there aren't any build regressions.

> As I said, we don't have any money to pay you.  If you consider it too
> expensive to maintain, then drop it.

It's only expensive because CMake 2.4.5 users aren't being pro-active
in testing.  It's repeated stable/release candidates that are really
really expensive.   When you don't test till after a stable release
has gone out then it's very much in the really expensive bracket.

The fact that stuff that could have easily been caught by end users
testing in release candidates of 2.8.1 is what pisses me off, all my
repeated calls for testing and the time I gave the community it seems
wasn't enough.  There are quite a few users who do make the effort,
these are the hero's of the community, others who waited till it after
the release are the ones who effectively casting all their efforts in
vain, as we're reset back to square one with a new series of
2.8.2-rc's and final 2.8.2 now required.

> If support for CMake 2.4.5 is contingent upon me alone testing every release
> that you put out, I cannot make any promises to do that.  I'll do what I
> can, but I cannot guarantee anything.  I like my job, and I intend to keep
> it.

We'll if you and others who want CMake 2.4.5 support can't afford to
make sure the OSG releases build it then there is nothing I can do.
If we don't know about problems we can't fix them.

> I've already said that I'll try to set up a CDash target for the trunk here
> in the lab.  Hopefully that's enough to satisfy your needs.

This will be a major step forward, having a nightly build of svn/trunk
and the latest stable branch (OpenSceneGraph-2.8) is one of the most
effectively ways of catching problems early.

It's not a total replacement for actual human testing though, whether
something compiles or not is only part of the story, we also need to
know if the OSG actual runs well against peoples applications prior to
releases.

> As far as gratitude, look, I'm not looking for a trophy or anything.  I just
> think that your contributors should be given a little respect.

I do appreciate your contributions, but that won't mean that I will
shy away from calling out problems when I see them.  The build problem
was minor problem easily dealt with, but the lack of community testing
prior to a release is a big problem here - as fixing problems after
releases is far more expensive, both for me and all those who
contribute to getting releases out the door.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Jason Daly]

Robert Osfield wrote:

Hi Jason,

Your rant shows you didn't grasp the point of my earlier email.
  


And your responses show that you didn't grasp the point of mine.

You seem to still be under the impression that I expect you to continue 
supporting CMake 2.4.5, no matter what.  Let me be clear here:


*If you don't want to support CMake 2.4.5 anymore, then by all means 
don't support it*


As I said, we don't have any money to pay you.  If you consider it too 
expensive to maintain, then drop it.  We'll be fine with 2.8.0 until we 
can get a newer version of CMake.  I personally find it hard to believe 
that maintaining RHEL 5 support is any harder than maintaining, say, 
IRIX support, but I'm not the one doing the maintenance, so what I 
believe is irrelevant.


If support for CMake 2.4.5 is contingent upon me alone testing every 
release that you put out, I cannot make any promises to do that.  I'll 
do what I can, but I cannot guarantee anything.  I like my job, and I 
intend to keep it.


I've already said that I'll try to set up a CDash target for the trunk 
here in the lab.  Hopefully that's enough to satisfy your needs.


As far as gratitude, look, I'm not looking for a trophy or anything.  I 
just think that your contributors should be given a little respect.  I 
just thought you were out of line with the way you characterized me in 
your last e-mail.  You made it sound like I'm taking OSG and using it 
and expecting you to handle all my needs without me giving anything 
back.  Nothing could be farther from the truth, and I just didn't 
appreciate being painted in that light.


I could say more, but I'd rather see this thread die.  It's stressing me 
out.


--"J"

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Robert Osfield]

Hi Jason,

Your rant shows you didn't grasp the point of my earlier email.

A couple of point that must be made clear.  All support costs me time
and therefore income - I don't get to charge anyone for the time it
takes me to do public support, I don't get to charge anyone for making
point releases, dev releases, release candidates.   All the time I
spend on general support like this is time I can't spend on paid work.
 Have a think about your salary per week, and then give away a half of
this for this for support of other people, if you can do this then
you'd be in stronger position to go about ranting at me not being
grateful.

Support for niche tools like out of date versions of CMake *directly*
costs me time and money.  Please remember that CMake 2.4.6 was the
reference version that we used when we ported to CMake two and half
years ago, so 2.4.5 was out of date even then.  It's very much a
luxury that we are able to support Cmake 2.4.5 at all.

The case of CMake 2.4.5 is just one small example of the different
build tool combinations we have to deal with, the more niche each of
the tools is the less exposure it'll have from others testing against
it, this in turn means that those who want the luxury of these niche
tools absolutely have to engage much more pro-atively with testing.
It's very much a case of use or or loose it.

And it's good enough to start testing after the horse has bolted -
i.e. after a stable release goes out, as the process of making stable
release is very expensive in time and money for me and the rest of the
community.  Delaying a release by a day to get something right only
costs me a days in salary, having to make another release costs me
several weeks - it's not just a little bit more, it's an order of
magnitude more expensive.

Robert.

On Sun, Jun 7, 2009 at 8:40 AM, Jason Daly wrote:
>
> Oh, boy.  Where to begin.  First of all, I don't have a clue how this
> discussion got out of hand.  We started out with a simple issue that showed
> up on a CentOS box.  It couldn't compile the recently released OSG 2.8.1
> version.  The issue came down to the fact that CentOS and Red Hat Enterprise
> Linux only have a 2.4.5 binary version available.  There was friction
> between the community that said to just upgrade to 2.6, and the CentOS users
> and administrators that tried to explain that it is difficult to do that in
> a large enterprise environment.  I jumped into this thread to try and help
> both parties understand the needs of the other.  Instead of a calm
> resolution, I've now been subjected to a rant from the OSG czar who says I
> need to contribute more.
>
> Responses inline below:
>
>
> Robert Osfield wrote:
>
> The loss in perspective is that the illusion that RHEL/CentOS and all
> the other long term supported linux distributions can bundle not only
> the core operating systems but ten's of thousands of other open source
> tools as one single supported and consistent entity.
>
> No other operating system vendors attempt to do this - they just ship
> the operating systems and the all the rest of the tools are provided
> by extra separate entitities and typically provided by 3rd parties.
> Some of these third party apps might rev at the same rate as the
> underlying OS, but typically don't.
>
>
> I find it odd that someone who uses and advocates Linux as much as you would
> question the practice of bundling the OS and applications and supporting
> them.  It's not just Red Hat and CentOS that do this.  Pretty much every
> Linux distribution does it.  In the case of the Enterprise distros, the
> support comes from paid contracts which help with security fixes, and
> addressing any critical problems that arise.  In the case of the free
> distributions, the support comes from the community.  In reality there's not
> much difference in software between Red Hat Enterprise and Fedora.  RHEL 5
> matches up almost exactly with Fedora 6, for example.  The difference is in
> the frequency of releases, the continuous support with minor bug and
> security fixes (often back-ported from upstream revisions), and the ability
> to centrally manage updates of client systems (when new updates come out,
> you just log on to a web site and press "Go", and all of your workstations
> are magically updated).
>
>
> Now it's very cool that linux distributions do attempt this almost
> impossible feat, but and it is humongous but there are problems with
> this approach of bundling practically everything together and rev's at
> the same rate is that in the 3rd party vendors can't be expected to
> pay for the support for this locked in versions of their software for
> the benefit of the linux distribution vendors.
>
> Of course not.  The customers pay the distribution provider for that
> support.  In turn, the distribution's own developers and engineers work with
> each 3rd party provider to integrate those packages into the distribution
> successfully.  OSG is not part of RHEL, which is probably why you

Re: [osg-users] build errors with 2.8.1

[Philip Lowman]

On Sun, Jun 7, 2009 at 3:40 AM, Jason Daly  wrote:

>  Oh, boy.  Where to begin.  First of all, I don't have a clue how this
> discussion got out of hand.  We started out with a simple issue that showed
> up on a CentOS box.  It couldn't compile the recently released OSG 2.8.1
> version.  The issue came down to the fact that CentOS and Red Hat Enterprise
> Linux only have a 2.4.5 binary version available.  There was friction
> between the community that said to just upgrade to 2.6, and the CentOS users
> and administrators that tried to explain that it is difficult to do that in
> a large enterprise environment.  I jumped into this thread to try and help
> both parties understand the needs of the other.  Instead of a calm
> resolution, I've now been subjected to a rant from the OSG czar who says I
> need to contribute more.
>

I stopped reading about here.

-- 
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Jason Daly]

Jean-Sébastien Guay wrote:

Hi all,

I, for one, would really like to thank you for the time you spend 
helping others and contributing, Jason. Since I've been here I've tried 
to take example on you and other people who have been active for a very 
long time on this list.


I don't really have any opinion on the whole enterprise distros issue, 
but I'd like to answer this at least:


  
For my part, I've glanced at the CDash site in the past, but I haven't 
had the chance to make myself familiar with it yet.  If it would help as 
much as you say, then I'll make an effort to get involved with it as 
soon as I can.  If someone familiar can e-mail me a quick-start guide 
(or a link to one), that would help.



All the info is here:

http://www.openscenegraph.org/projects/osg/wiki/Build/CDash

It's pretty simple, the short and sweet of it is:

1. Enable dashboard reports in CMake, then generate.
2. Make a script you can add to a cron job that will run the build
target called "Nightly".
3. Add that cron job to run at the time of your choosing.
  


Thanks, J-S.  I'll be sure to look into setting this up in our lab.

--"J"


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Jean-Sébastien Guay]

Hi all,

I, for one, would really like to thank you for the time you spend 
helping others and contributing, Jason. Since I've been here I've tried 
to take example on you and other people who have been active for a very 
long time on this list.


I don't really have any opinion on the whole enterprise distros issue, 
but I'd like to answer this at least:


For my part, I've glanced at the CDash site in the past, but I haven't 
had the chance to make myself familiar with it yet.  If it would help as 
much as you say, then I'll make an effort to get involved with it as 
soon as I can.  If someone familiar can e-mail me a quick-start guide 
(or a link to one), that would help.


All the info is here:

http://www.openscenegraph.org/projects/osg/wiki/Build/CDash

It's pretty simple, the short and sweet of it is:

1. Enable dashboard reports in CMake, then generate.
2. Make a script you can add to a cron job that will run the build
   target called "Nightly".
3. Add that cron job to run at the time of your choosing.

I personally keep a working copy from SVN just for the nightly builds, 
because if I have any local modifications (i.e. I'm in the process of 
getting a submission in shape, for example) the nightly build will 
refuse to run. That also makes it so I know I have a known-good OSG 
build from the last night on my machine at all times, so I can do some 
testing with that too.


I have to agree that even if you don't use every single developer 
release in your own software (we don't either), regular build testing 
helps keep quality up. And by looking at which builds fail and why, 
Robert can fix build issues without anyone ever needing to report them 
on this list... It's not a complete testing solution (we'd need some 
automatic-run unit tests for that) but it's a good first step.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   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] build errors with 2.8.1

[Jason Daly]

Oh, boy.  Where to begin.  First of all, I don't have a clue how this 
discussion got out of hand.  We started out with a simple issue that 
showed up on a CentOS box.  It couldn't compile the recently released 
OSG 2.8.1 version.  The issue came down to the fact that CentOS and Red 
Hat Enterprise Linux only have a 2.4.5 binary version available.  There 
was friction between the community that said to just upgrade to 2.6, and 
the CentOS users and administrators that tried to explain that it is 
difficult to do that in a large enterprise environment.  I jumped into 
this thread to try and help both parties understand the needs of the 
other.  Instead of a calm resolution, I've now been subjected to a rant 
from the OSG czar who says I need to contribute more.


Responses inline below:


Robert Osfield wrote:


The loss in perspective is that the illusion that RHEL/CentOS and all
the other long term supported linux distributions can bundle not only
the core operating systems but ten's of thousands of other open source
tools as one single supported and consistent entity.

No other operating system vendors attempt to do this - they just ship
the operating systems and the all the rest of the tools are provided
by extra separate entitities and typically provided by 3rd parties.
Some of these third party apps might rev at the same rate as the
underlying OS, but typically don't.
  


I find it odd that someone who uses and advocates Linux as much as you 
would question the practice of bundling the OS and applications and 
supporting them.  It's not just Red Hat and CentOS that do this.  Pretty 
much every Linux distribution does it.  In the case of the Enterprise 
distros, the support comes from paid contracts which help with security 
fixes, and addressing any critical problems that arise.  In the case of 
the free distributions, the support comes from the community.  In 
reality there's not much difference in software between Red Hat 
Enterprise and Fedora.  RHEL 5 matches up almost exactly with Fedora 6, 
for example.  The difference is in the frequency of releases, the 
continuous support with minor bug and security fixes (often back-ported 
from upstream revisions), and the ability to centrally manage updates of 
client systems (when new updates come out, you just log on to a web site 
and press "Go", and all of your workstations are magically updated).




Now it's very cool that linux distributions do attempt this almost
impossible feat, but and it is humongous but there are problems with
this approach of bundling practically everything together and rev's at
the same rate is that in the 3rd party vendors can't be expected to
pay for the support for this locked in versions of their software for
the benefit of the linux distribution vendors.


Of course not.  The customers pay the distribution provider for that 
support.  In turn, the distribution's own developers and engineers work 
with each 3rd party provider to integrate those packages into the 
distribution successfully.  OSG is not part of RHEL, which is probably 
why you haven't heard from any of them.


I'm also not sure why you think this is an "impossible feat".  It's 
actually a well-formed engineering process that works quite well.  Major 
issues are very rare and usually isolated to a small set of users, and 
Red Hat addresses the problems in a matter of days.




  This very thread is
about that fact that CentOS/RHEL have locked in versions of software
that is DIRECTLY cause support work for us - not just the CentOS/RHEL
users, but others who have nothing to do with developing or supporting
this distro's.   You might pay RHEL for support for doing this but are
you paying all the rest of the ecosystem like OSG community members
for the luxury of you using the tools that only come with a particular
RHEL.
  


I don't understand this claim at all.  If you actually read my last 
e-mail, I pointed out three possible solutions, only one of which 
involves any effort from you or the OSG community.  Please understand, 
we're really happy that you've supported the older CMake versions thus 
far, but we know that it's entirely your prerogative.  If you decide 
that supporting CMake 2.4.5 is too much work to continue, we'll be happy 
to stick with OSG 2.8 until the next version of Red Hat Enterprise is 
released with a more suitable version of CMake (or we'll make an 
exception and install a non-standard CMake version if the need becomes 
great enough).  As an example, we just recently upgraded to OSG 2.8 from 
2.2.  This is how most of the software on these distributions works.  As 
another example, we still develop with GTK 2.10, even though 2.16 was 
released some time ago.


We may be missing a few new features introduced in the new revisions of 
libraries like these, but we know for certain that our code will still 
work and that our customers' needs will be met.  When someone is paying 
you to develop and support a large software system, it's a n

Re: [osg-users] build errors with 2.8.1

[Robert Osfield]

Hi Jason,

On Fri, Jun 5, 2009 at 11:06 PM, Jason Daly wrote:
> There's no loss of perpective that I can detect.  I think we're all still
> dealing with facts here.  The fact is that there is currently no way to
> install CMake 2.6 on a Red Hat Enterprise or CentOS in a way that can be
> easily maintained and administered.  The sysadmin's response may be a bit
> haughty, but nothing he said was untrue.
>
> From what I can tell, there are three ways to approach this.  Either OSG can
> continue to support CMake 2.4.5 until RHEL catches up to 2.6, or the
> sysadmins can make an exception and make CMake 2.6 available without an RPM,
> or the developers can stay with the current version of OSG until the next
> CMake becomes available on their systems.

The loss in perspective is that the illusion that RHEL/CentOS and all
the other long term supported linux distributions can bundle not only
the core operating systems but ten's of thousands of other open source
tools as one single supported and consistent entity.

No other operating system vendors attempt to do this - they just ship
the operating systems and the all the rest of the tools are provided
by extra separate entitities and typically provided by 3rd parties.
Some of these third party apps might rev at the same rate as the
underlying OS, but typically don't.

Now it's very cool that linux distributions do attempt this almost
impossible feat, but and it is humongous but there are problems with
this approach of bundling practically everything together and rev's at
the same rate is that in the 3rd party vendors can't be expected to
pay for the support for this locked in versions of their software for
the benefit of the linux distribution vendors.  This very thread is
about that fact that CentOS/RHEL have locked in versions of software
that is DIRECTLY cause support work for us - not just the CentOS/RHEL
users, but others who have nothing to do with developing or supporting
this distro's.   You might pay RHEL for support for doing this but are
you paying all the rest of the ecosystem like OSG community members
for the luxury of you using the tools that only come with a particular
RHEL.

So this is perspective that is missing.   It's your companies choice
to use a distro with locked in versions of software, and there is a
cost of this that goes far beyond your own company.  Who's to pay for
this?

In the case of community like this core developers have to put up with
support hassles like this as just part of running a project, but we
need help, and help specifically from people who wish to use locked in
versions of software due to using CentOS/RHEL etc - you guys need to
spend the time in properly supporting software that you need, this
means allotting time and resources to help out with testing.  For
instance we have the CDash dashboard to tracking nightly builds.  Also
talk with your management about this issue - if you want the luxury of
using a fixed version of OS and associated tools then their is this
extra cost that you need to factor in, if you don't have the ability
to keep track of supported software then you have to pony up the 3rd
party support to cover this.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Robert Osfield]

Hi John,

Try removing your OpenSceneGraph/CMakeCache.text file and the re-run
./configure to see if that kicks CMake into properly checking all the
dependencies.

Also try disabling the aggressive warnings to see if that prevents gcc
spitting out errors when compiling against ITK.

Robert.

On Fri, Jun 5, 2009 at 10:25 PM, John Kelso wrote:
> Hi!
>
> I missed the earlier note about the cmake problem being fixed in the branch.
> Sorry to make noise about a fixed problem.  I do test (and squawk) when I
> can, but as we all know, life sometimes has other plans.
>
> I installed DCMTK in a local directory, and just tried to rebuild 2.8.1 in a
> clean build directory.
>
> The cmake command I used was:
>
>>  cmake \
>>>
>>>     -D CMAKE_INSTALL_PREFIX=$HEVROOT/apps/osg/osg-2.x/installed \
>>>     -D BUILD_OSG_EXAMPLES=1 \
>>>     -D INVENTOR_INCLUDE_DIR=`coin-config --prefix`/include \
>>>     -D INVENTOR_LIBRARY=`coin-config --prefix`/lib/libCoin.so \
>>>     -D DCMTK_DIR=$HEVROOT/apps/dcmtk/dcmtk-3.x \
>>>     ../OpenSceneGraph
>
> When I make, it seems to still want to use our installed ITK for the DICOMED
> plugin, and bombs with the same errors.
>
> I also tried setting DCMTK_INCLUDE_DIRS and DCMTK_LIBRARIES instead, but got
> the same result.
>
> Is there something else I need to do to get OSG to use DCMTK instead of
> ITK?
>
> Thanks for your patience,
>
> John
>
>
> On Fri, 5 Jun 2009, Robert Osfield wrote:
>
>> Hi John and Jason,
>>
>> Can we get a little perspective on this issue.  The build problem was
>> a warning that we've already fixed in OSG-2.8 branch.  As for snooty
>> admin's, best to leave them alone if helping you out is too much for
>> them.
>>
>> The warning that occurred in OSG-2.8.1 because of something I merged
>> in from svn/trunk was in the release candidates and I made repeated
>> calls for testing... Had we known about the issue it would have been
>> fixed in less than five minutes and well before the release.  So
>> PLEASE don't ignore the calls for testing.
>>
>> John, the errors you are getting in ITK look to have nothing to do
>> with the OSG.  Can you please look into this and provide feedback on
>> what is wrong.  There is chance the high levels of warning we use in
>> the OSG build now could be causing the compile to emit errors instead
>> of warnings when compiling ITK.
>>
>> Robert.
>> ___
>> 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Jason Daly]

Hi, Robert,


Robert Osfield wrote:

Hi John and Jason,

Can we get a little perspective on this issue.  The build problem was
a warning that we've already fixed in OSG-2.8 branch.  As for snooty
admin's, best to leave them alone if helping you out is too much for
them.
  


There's no loss of perpective that I can detect.  I think we're all 
still dealing with facts here.  The fact is that there is currently no 
way to install CMake 2.6 on a Red Hat Enterprise or CentOS in a way that 
can be easily maintained and administered.  The sysadmin's response may 
be a bit haughty, but nothing he said was untrue.


From what I can tell, there are three ways to approach this.  Either 
OSG can continue to support CMake 2.4.5 until RHEL catches up to 2.6, or 
the sysadmins can make an exception and make CMake 2.6 available without 
an RPM, or the developers can stay with the current version of OSG until 
the next CMake becomes available on their systems.


From your response, it sounds like option 1 is still viable, which is 
good  :-)




The warning that occurred in OSG-2.8.1 because of something I merged
in from svn/trunk was in the release candidates and I made repeated
calls for testing... Had we known about the issue it would have been
fixed in less than five minutes and well before the release.  So
PLEASE don't ignore the calls for testing.
  


I think we all understand what happened.  It's unfortunate, but I don't 
think it's a huge problem (IIRC, there are already plans for a 2.8.2 
release anyway).


As for testing, I test OSG releases when I can.  There are times I can 
test every RC during a release push, and there are times when I can't 
test any of them.  I'd like to be able to test every single one, but my 
first priority is to my job and the tasks I have to do that day.  I 
can't help it if those tasks keep me from testing an OSG release 
candidate.  I'm sure a lot of folks are in the same boat.


Several times in the past you've mentioned that you're busy with paid 
work and can't do as much support as you'd like to, so I'm sure you know 
where I'm coming from.  I'm not complaining about anything, it's just 
the way things worked out.


--"J"

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[John Kelso]

Hi!

I missed the earlier note about the cmake problem being fixed in the branch.
Sorry to make noise about a fixed problem.  I do test (and squawk) when I
can, but as we all know, life sometimes has other plans.

I installed DCMTK in a local directory, and just tried to rebuild 2.8.1 in a
clean build directory.

The cmake command I used was:


  cmake \

 -D CMAKE_INSTALL_PREFIX=$HEVROOT/apps/osg/osg-2.x/installed \
 -D BUILD_OSG_EXAMPLES=1 \
 -D INVENTOR_INCLUDE_DIR=`coin-config --prefix`/include \
 -D INVENTOR_LIBRARY=`coin-config --prefix`/lib/libCoin.so \
 -D DCMTK_DIR=$HEVROOT/apps/dcmtk/dcmtk-3.x \
 ../OpenSceneGraph


When I make, it seems to still want to use our installed ITK for the DICOMED
plugin, and bombs with the same errors.

I also tried setting DCMTK_INCLUDE_DIRS and DCMTK_LIBRARIES instead, but got
the same result.

Is there something else I need to do to get OSG to use DCMTK instead of
ITK?

Thanks for your patience,

John


On Fri, 5 Jun 2009, Robert Osfield wrote:


Hi John and Jason,

Can we get a little perspective on this issue.  The build problem was
a warning that we've already fixed in OSG-2.8 branch.  As for snooty
admin's, best to leave them alone if helping you out is too much for
them.

The warning that occurred in OSG-2.8.1 because of something I merged
in from svn/trunk was in the release candidates and I made repeated
calls for testing... Had we known about the issue it would have been
fixed in less than five minutes and well before the release.  So
PLEASE don't ignore the calls for testing.

John, the errors you are getting in ITK look to have nothing to do
with the OSG.  Can you please look into this and provide feedback on
what is wrong.  There is chance the high levels of warning we use in
the OSG build now could be causing the compile to emit errors instead
of warnings when compiling ITK.

Robert.
___
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] build errors with 2.8.1

[Robert Osfield]

Hi John and Jason,

Can we get a little perspective on this issue.  The build problem was
a warning that we've already fixed in OSG-2.8 branch.  As for snooty
admin's, best to leave them alone if helping you out is too much for
them.

The warning that occurred in OSG-2.8.1 because of something I merged
in from svn/trunk was in the release candidates and I made repeated
calls for testing... Had we known about the issue it would have been
fixed in less than five minutes and well before the release.  So
PLEASE don't ignore the calls for testing.

John, the errors you are getting in ITK look to have nothing to do
with the OSG.  Can you please look into this and provide feedback on
what is wrong.  There is chance the high levels of warning we use in
the OSG build now could be causing the compile to emit errors instead
of warnings when compiling ITK.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Jason Daly]

John Kelso wrote:

Below is from our sysadmin when I asked him about getting a newer version cmake.

Any comments, anyone?
  


I've seen several instances of the typical OSS "bigger, better, faster" 
mentality clashing with the "if it ain't broke, don't fix it" mentality 
of the enterprise distros.  It's kind of inevitable.  On the other hand, 
without distros like Red Hat Enterprise, you'd never have any large 
businesses running Linux.  There's just no way anyone could maintain any 
kind of large system environment if it changes major revisions every 4-6 
months.


So far, I've been happy that OSG has kept support for CMake 2.4.5, which 
is the latest that we have available.  If that's been broken, it just 
makes it harder for us to upgrade, at least until RHEL 6 is released 
next year (most likely my supervisor will elect to stick with 2.8 until 
then).


Running a private install out of a home directory is certainly possible, 
but it's not really compatible with the concept of an enterprise distro 
(it's kind of a hack, rather than an actual fix).




Can we really be the only site having this problem?
  


Take heart, you are not alone!  :-)

--"J"


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Jason Daly]

John Kelso wrote:

Hi,

I'm a bit surprised by this because as far as I know we have a fairly recent
version of Centos.  Are there no other Centos users out there trying 2.8.1?
  


We're using RHEL 5, but we haven't tried 2.8.1 yet (2.8.0 is meeting our 
needs for now).




Is cmake-2.4.8 "really old"?

That said, I'll try to get our system guy to install a newer version of
cmake.
  


The biggest problem is that there's no 2.6.x RPM for RHEL 5 (or Centos 
5).  You can always compile and install a tarball, but that makes 
administration of a lot of workstations a bit more difficult.


--"J"

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[John Kelso]

Below is from our sysadmin when I asked him about getting a newer version cmake.

Any comments, anyone?

Can we really be the only site having this problem?

Thanks again,

John

-- Forwarded message --
We're using a current version of the most recent, one of the most popular 
Enterprise Linux distribution on the planet.  They chose to take a shortcut in 
their coding style that's not backward compatible.  And CentOS 5.3's cmake 
2.4.7 was released 2007-07-17, not even two years ago...is that classified as 
"really old"?  Keep in mind CentOS/RHEL has a 7 year lifespan, and they don't 
update package versions very often, just nice, warm & fuzzy stable fixes.  It 
keeps things running, minimizing breakage, which is the whole point of an 
enterprise distribution.


From the cmake FAQ 
, 
it appears the ability to have empty ENDIF() started in 2.6.0, released 
2008-05-06 . 
IMHO, they made a bad choice coding to a recent buildsystem requirement.



On 06/05/2009 11:40 AM, John Kelso wrote:

Any idea if we can get a newer cmake?  Please see below for gory details.

Many thanks,

John


-- Forwarded message --
Date: Fri, 5 Jun 2009 11:38:39 -0400 (EDT)
From: John Kelso 
To: OpenSceneGraph Users 
Subject: Re: build errors with 2.8.1

Hi,

I'm a bit surprised by this because as far as I know we have a fairly recent
version of Centos.  Are there no other Centos users out there trying 2.8.1?


cat /etc/redhat-release

CentOS release 5.3 (Final)

which incudes this version of cmake:

rpm -q cmake

cmake-2.4.8-3.el5.i386

Is cmake-2.4.8 "really old"?

That said, I'll try to get our system guy to install a newer version of
cmake.

Thanks again,

John

On Fri, 5 Jun 2009, Robert Osfield wrote:


Hi Paul,

On Thu, Jun 4, 2009 at 8:11 PM, Paul
Melis wrote:

First, try this:

In applications/osgversion/CMakeLists.txt change ENDIF() to
ENDIF(OSG_MAINTAINER)
That line looks fishy.


Cmake used to require the the IF() ENDIF() matched but this
requirement was dropped, and now the OSG-2.9.x and svn/trunk has been
cleaned up to not have the matching entries as it makes the code far
more readable and maintainable.

I was under the impression that this wouldn't cause too many problems
except for really old CMake versions.

Robert.
___
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] build errors with 2.8.1

[Philip Lowman]

On Fri, Jun 5, 2009 at 11:38 AM, John Kelso  wrote:

> Hi,
>
> I'm a bit surprised by this because as far as I know we have a fairly
> recent
> version of Centos.  Are there no other Centos users out there trying 2.8.1?
>
>  cat /etc/redhat-release
>>
> CentOS release 5.3 (Final)
>
> which incudes this version of cmake:
>
>> rpm -q cmake
>>
> cmake-2.4.8-3.el5.i386
>
> Is cmake-2.4.8 "really old"?
>
> That said, I'll try to get our system guy to install a newer version of
> cmake.
>
> Thanks again,


CMake 2.4.8 isn't "really old" but many people have switched to 2.6.x
because of the new features present in it and also because 2.4.x is no
longer being maintained.

You can always run CMake out of your home directory without bothering your
systems guy.  There are prebuilt versions of it for Linux available here.
http://www.cmake.org/cmake/resources/software.html

-- 
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Philip Lowman]

On Fri, Jun 5, 2009 at 4:36 AM, Robert Osfield wrote:

> Hi Paul,
>
> On Thu, Jun 4, 2009 at 8:11 PM, Paul
> Melis wrote:
> > First, try this:
> >
> > In applications/osgversion/CMakeLists.txt change ENDIF() to
> > ENDIF(OSG_MAINTAINER)
> > That line looks fishy.
>
> Cmake used to require the the IF() ENDIF() matched but this
> requirement was dropped, and now the OSG-2.9.x and svn/trunk has been
> cleaned up to not have the matching entries as it makes the code far
> more readable and maintainable.
>
> I was under the impression that this wouldn't cause too many problems
> except for really old CMake versions.


Here's the problem that caused the configure warning.

The variable below (which is on the first line in the trunk's
CMakeLists.txt) would need to be added to the OpenSceneGraph-2.8.0 branch if
we wanted to take advantage of unmatched if/endif in that branch.  This
change on the trunk came in r9908 and wasn't applied to the 2.8 branch.

set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE)

This allows the unmatched if/else/endif to work on CMake 2.4.4-2.4.8.  The
variable is not needed in CMake 2.6 as it automatically supports the
feature.

The change in r10313 does fix the warning.  To prevent this warning from
cropping up again I would suggest either applying r9908 to the 2.8 branch or
be very careful backporting CMakeLists.txt files and changes from the trunk
to the OpenSceneGraph-2.8 branch since they all no longer have matching
else/endif constructs.

-- 
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[John Kelso]

Hi,

I'm a bit surprised by this because as far as I know we have a fairly recent
version of Centos.  Are there no other Centos users out there trying 2.8.1?


cat /etc/redhat-release

CentOS release 5.3 (Final)

which incudes this version of cmake:

rpm -q cmake

cmake-2.4.8-3.el5.i386

Is cmake-2.4.8 "really old"?

That said, I'll try to get our system guy to install a newer version of
cmake.

Thanks again,

John

On Fri, 5 Jun 2009, Robert Osfield wrote:


Hi Paul,

On Thu, Jun 4, 2009 at 8:11 PM, Paul
Melis wrote:

First, try this:

In applications/osgversion/CMakeLists.txt change ENDIF() to
ENDIF(OSG_MAINTAINER)
That line looks fishy.


Cmake used to require the the IF() ENDIF() matched but this
requirement was dropped, and now the OSG-2.9.x and svn/trunk has been
cleaned up to not have the matching entries as it makes the code far
more readable and maintainable.

I was under the impression that this wouldn't cause too many problems
except for really old CMake versions.

Robert.
___
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] build errors with 2.8.1

[Robert Osfield]

Hi John.

These aren't errors in the OSG's build, but in the 3rd party library
(ITK) that it's pulliing in.  I am very surprised that errors are
popping up.  Try reducing the verbosity of OSG warning dectition by
setting  OSG_USE_AGGRESSIVE_WARNINGS to OFF using ccmake make.

The other option would be to grab DCMTK as it's a better loader for
dicom files anyway, and if you have DCMTK then the dicom plugin won't
try to use ITK.

Robert.

2009/6/4 John Kelso :
> Hi again,
>
> I made the change in CMakeLists.txt and cmake was happy.  It still bombs
> when
> building- it's in the dicom plugin.
>
> We have installed:
>>
>> rpm -q InsightToolkit
>
> InsightToolkit-2.8.1-5.fc6.i386
>
> There's a large number of repetitious errors., included below.
>
> Any ideas?
>
> Many thanks,
>
> John
>
> Scanning dependencies of target osgdb_dicom
> Building CXX object
> src/osgPlugins/dicom/CMakeFiles/osgdb_dicom.dir/ReaderWriterDICOM.o
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:306:
> error: floating-point literal cannot appear in a constant-expression
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:306:
> warning: ISO C++ forbids initialization of member constant ‘zero’ of
> non-integral type ‘const float’
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:308:
> error: floating-point literal cannot appear in a constant-expression
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:308:
> warning: ISO C++ forbids initialization of member constant ‘one’ of
> non-integral type ‘const float’
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:310:
> error: floating-point literal cannot appear in a constant-expression
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:310:
> warning: ISO C++ forbids initialization of member constant ‘maxval’ of
> non-integral type ‘const float’
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:329:
> error: floating-point literal cannot appear in a constant-expression
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:329:
> warning: ISO C++ forbids initialization of member constant ‘zero’ of
> non-integral type ‘const double’
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:331:
> error: floating-point literal cannot appear in a constant-expression
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:331:
> warning: ISO C++ forbids initialization of member constant ‘one’ of
> non-integral type ‘const double’
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:333:
> error: floating-point literal cannot appear in a constant-expression
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:333:
> warning: ISO C++ forbids initialization of member constant ‘maxval’ of
> non-integral type ‘const double’
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:352:
> error: floating-point literal cannot appear in a constant-expression
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:352:
> warning: ISO C++ forbids initialization of member constant ‘zero’ of
> non-integral type ‘const long double’
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:354:
> error: floating-point literal cannot appear in a constant-expression
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:354:
> warning: ISO C++ forbids initialization of member constant ‘one’ of
> non-integral type ‘const long double’
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:356:
> error: floating-point literal cannot appear in a constant-expression
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:356:
> warning: ISO C++ forbids initialization of member constant ‘maxval’ of
> non-integral type ‘const long double’
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:55: error:
> floating-point literal cannot appear in a constant-expression
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:55: warning:
> ISO C++ forbids initialization of member constant ‘e’ of non-integral type
> ‘const double’
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:56: error:
> floating-point literal cannot appear in a constant-expression
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:56: warning:
> ISO C++ forbids initialization of member constant ‘log2e’ of non-integral
> type ‘const double’
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:57: error:
> floating-point literal cannot appear in a constant-expression
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:57: warning:
> ISO C++ forbids initialization of member constant ‘log10e’ of non-integral
> type ‘const double’
> /usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:58: error:
> floating-point litera

Re: [osg-users] build errors with 2.8.1

[Robert Osfield]

Hi Paul,

On Thu, Jun 4, 2009 at 8:11 PM, Paul
Melis wrote:
> First, try this:
>
> In applications/osgversion/CMakeLists.txt change ENDIF() to
> ENDIF(OSG_MAINTAINER)
> That line looks fishy.

Cmake used to require the the IF() ENDIF() matched but this
requirement was dropped, and now the OSG-2.9.x and svn/trunk has been
cleaned up to not have the matching entries as it makes the code far
more readable and maintainable.

I was under the impression that this wouldn't cause too many problems
except for really old CMake versions.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[John Kelso]

Hi again,

I made the change in CMakeLists.txt and cmake was happy.  It still bombs when
building- it's in the dicom plugin.

We have installed:

rpm -q InsightToolkit

InsightToolkit-2.8.1-5.fc6.i386

There's a large number of repetitious errors., included below.

Any ideas?

Many thanks,

John

Scanning dependencies of target osgdb_dicom
Building CXX object 
src/osgPlugins/dicom/CMakeFiles/osgdb_dicom.dir/ReaderWriterDICOM.o
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:306: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:306: 
warning: ISO C++ forbids initialization of member constant ‘zero’ of 
non-integral type ‘const float’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:308: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:308: 
warning: ISO C++ forbids initialization of member constant ‘one’ of 
non-integral type ‘const float’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:310: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:310: 
warning: ISO C++ forbids initialization of member constant ‘maxval’ of 
non-integral type ‘const float’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:329: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:329: 
warning: ISO C++ forbids initialization of member constant ‘zero’ of 
non-integral type ‘const double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:331: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:331: 
warning: ISO C++ forbids initialization of member constant ‘one’ of 
non-integral type ‘const double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:333: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:333: 
warning: ISO C++ forbids initialization of member constant ‘maxval’ of 
non-integral type ‘const double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:352: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:352: 
warning: ISO C++ forbids initialization of member constant ‘zero’ of 
non-integral type ‘const long double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:354: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:354: 
warning: ISO C++ forbids initialization of member constant ‘one’ of 
non-integral type ‘const long double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:356: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:356: 
warning: ISO C++ forbids initialization of member constant ‘maxval’ of 
non-integral type ‘const long double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:55: error: 
floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:55: warning: ISO 
C++ forbids initialization of member constant ‘e’ of non-integral type ‘const 
double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:56: error: 
floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:56: warning: ISO 
C++ forbids initialization of member constant ‘log2e’ of non-integral type 
‘const double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:57: error: 
floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:57: warning: ISO 
C++ forbids initialization of member constant ‘log10e’ of non-integral type 
‘const double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:58: error: 
floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:58: warning: ISO 
C++ forbids initialization of member constant ‘ln2’ of non-integral type ‘const 
double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:59: error: 
floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:59: warning: ISO 
C++ forbids initialization of member constant ‘ln10’ of non-integral type 
‘const double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:60: error

Re: [osg-users] build errors with 2.8.1

[Paul Melis]

John Kelso wrote:
> Hi,
>
> cmake 2.4-patch 8, that came with CentOS release 5.3.
>
> Our systems have been upgraded since my last OSG build, so I'll see if
> there's any relationship.  If I get stuck I'll mail again.
>
> Should I see if our system guy can install a newer cmake?
One thing cmake 2.6 has over 2.4 is that it seems to be smarter when it
comes to linking.
With 2.4 you get some kind of relinking stage when doing 'make install',
which doesn't occur with 2.6
I can't say anything about the other differences between 2.4 and 2.6

Paul
>
> Thanks again,
>
> John
>
> On Thu, 4 Jun 2009, Paul Melis wrote:
>
>> Ulrich Hertlein wrote:
>>> Hi John,
>>>
>>> On 4/6/09 7:24 PM, John Kelso wrote:
 After downloading 2.8.1 and typing cmake, I got this error:

 "The end of a CMakeLists file was reached with an IF statement that
 was not
 closed properly. Within the directory:
 /usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion



 The arguments are: OSG_MAINTAINER"

 Are all bets off from this point, or can this be safely ignored?

 I plowed ahead anyway and the make died a horrible death. Before I
 waste
 time figuring out why, I'm wondering if I could get some advice about
 the
 relevance and importance of the cmake message.
>>>
>>> You're probably using a version of cmake that is too old (maybe 2.4?)
>> The toplevel CMakeLists.txt contains
>>
>> IF(WIN32)
>>CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
>> ELSE(WIN32)
>>IF(APPLE)
>>CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
>>ELSE(APPLE)
>>CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR)
>>ENDIF(APPLE)
>> ENDIF(WIN32)
>>
>> so either these checks are not strict enough and your version of CMake
>> is screwing up, or something else is going on.
>> What version of CMake do you use?
>>
>> Paul
>> ___
>> 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

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Paul Melis]

Paul Melis wrote:
> Paul Melis wrote:
>   
>> John Kelso wrote:
>>   
>> 
>>> Hi,
>>>
>>> cmake 2.4-patch 8, that came with CentOS release 5.3.
>>>
>>> Our systems have been upgraded since my last OSG build, so I'll see if
>>> there's any relationship.  If I get stuck I'll mail again.
>>>
>>> Should I see if our system guy can install a newer cmake?
>>> 
>>>   
>> First, try this:
>>
>> In applications/osgversion/CMakeLists.txt change ENDIF() to
>> ENDIF(OSG_MAINTAINER)
>> That line looks fishy.
>>   
>> 
> If that solves it for you then I don't know how it ever got through the
> release candidate testing. The ENDIF() was introduced in rc4, and even
> that was followed by rc5. Perhaps it's only CMake 2.4 that stumbles over
> this.
>
> Checking...
>
> Indeed, no warning with 2.6, while 2.4 DOES warn (but continues with
> configuring).
>   
Robert, I fixed this on the 2.8 branch (r10313).

Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Paul Melis]

Paul Melis wrote:
> John Kelso wrote:
>   
>> Hi,
>>
>> cmake 2.4-patch 8, that came with CentOS release 5.3.
>>
>> Our systems have been upgraded since my last OSG build, so I'll see if
>> there's any relationship.  If I get stuck I'll mail again.
>>
>> Should I see if our system guy can install a newer cmake?
>> 
> First, try this:
>
> In applications/osgversion/CMakeLists.txt change ENDIF() to
> ENDIF(OSG_MAINTAINER)
> That line looks fishy.
>   
If that solves it for you then I don't know how it ever got through the
release candidate testing. The ENDIF() was introduced in rc4, and even
that was followed by rc5. Perhaps it's only CMake 2.4 that stumbles over
this.

Checking...

Indeed, no warning with 2.6, while 2.4 DOES warn (but continues with
configuring).

Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Paul Melis]

John Kelso wrote:
> Hi,
>
> cmake 2.4-patch 8, that came with CentOS release 5.3.
>
> Our systems have been upgraded since my last OSG build, so I'll see if
> there's any relationship.  If I get stuck I'll mail again.
>
> Should I see if our system guy can install a newer cmake?
First, try this:

In applications/osgversion/CMakeLists.txt change ENDIF() to
ENDIF(OSG_MAINTAINER)
That line looks fishy.

Paul

>
> Thanks again,
>
> John
>
> On Thu, 4 Jun 2009, Paul Melis wrote:
>
>> Ulrich Hertlein wrote:
>>> Hi John,
>>>
>>> On 4/6/09 7:24 PM, John Kelso wrote:
 After downloading 2.8.1 and typing cmake, I got this error:

 "The end of a CMakeLists file was reached with an IF statement that
 was not
 closed properly. Within the directory:
 /usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion



 The arguments are: OSG_MAINTAINER"

 Are all bets off from this point, or can this be safely ignored?

 I plowed ahead anyway and the make died a horrible death. Before I
 waste
 time figuring out why, I'm wondering if I could get some advice about
 the
 relevance and importance of the cmake message.
>>>
>>> You're probably using a version of cmake that is too old (maybe 2.4?)
>> The toplevel CMakeLists.txt contains
>>
>> IF(WIN32)
>>CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
>> ELSE(WIN32)
>>IF(APPLE)
>>CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
>>ELSE(APPLE)
>>CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR)
>>ENDIF(APPLE)
>> ENDIF(WIN32)
>>
>> so either these checks are not strict enough and your version of CMake
>> is screwing up, or something else is going on.
>> What version of CMake do you use?
>>
>> Paul
>> ___
>> 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
>

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[John Kelso]

Hi,

cmake 2.4-patch 8, that came with CentOS release 5.3.

Our systems have been upgraded since my last OSG build, so I'll see if
there's any relationship.  If I get stuck I'll mail again.

Should I see if our system guy can install a newer cmake?

Thanks again,

John

On Thu, 4 Jun 2009, Paul Melis wrote:


Ulrich Hertlein wrote:

Hi John,

On 4/6/09 7:24 PM, John Kelso wrote:

After downloading 2.8.1 and typing cmake, I got this error:

"The end of a CMakeLists file was reached with an IF statement that
was not
closed properly. Within the directory:
/usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion


The arguments are: OSG_MAINTAINER"

Are all bets off from this point, or can this be safely ignored?

I plowed ahead anyway and the make died a horrible death. Before I waste
time figuring out why, I'm wondering if I could get some advice about
the
relevance and importance of the cmake message.


You're probably using a version of cmake that is too old (maybe 2.4?)

The toplevel CMakeLists.txt contains

IF(WIN32)
   CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
ELSE(WIN32)
   IF(APPLE)
   CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
   ELSE(APPLE)
   CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR)
   ENDIF(APPLE)
ENDIF(WIN32)

so either these checks are not strict enough and your version of CMake
is screwing up, or something else is going on.
What version of CMake do you use?

Paul
___
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] build errors with 2.8.1

[Paul Melis]

Ulrich Hertlein wrote:
> Hi John,
>
> On 4/6/09 7:24 PM, John Kelso wrote:
>> After downloading 2.8.1 and typing cmake, I got this error:
>>
>> "The end of a CMakeLists file was reached with an IF statement that
>> was not
>> closed properly. Within the directory:
>> /usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion
>>
>>
>> The arguments are: OSG_MAINTAINER"
>>
>> Are all bets off from this point, or can this be safely ignored?
>>
>> I plowed ahead anyway and the make died a horrible death. Before I waste
>> time figuring out why, I'm wondering if I could get some advice about
>> the
>> relevance and importance of the cmake message.
>
> You're probably using a version of cmake that is too old (maybe 2.4?)
The toplevel CMakeLists.txt contains

IF(WIN32)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
ELSE(WIN32)
IF(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
ELSE(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR)
ENDIF(APPLE)
ENDIF(WIN32)

so either these checks are not strict enough and your version of CMake
is screwing up, or something else is going on.
What version of CMake do you use?

Paul
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] build errors with 2.8.1

[Ulrich Hertlein]

Hi John,

On 4/6/09 7:24 PM, John Kelso wrote:

After downloading 2.8.1 and typing cmake, I got this error:

"The end of a CMakeLists file was reached with an IF statement that was not
closed properly. Within the directory:
/usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion

The arguments are: OSG_MAINTAINER"

Are all bets off from this point, or can this be safely ignored?

I plowed ahead anyway and the make died a horrible death. Before I waste
time figuring out why, I'm wondering if I could get some advice about the
relevance and importance of the cmake message.


You're probably using a version of cmake that is too old (maybe 2.4?)

However, I've found that these messages can be ignored and the build would 
succeed.
What kind of errors are you getting?

Cheers,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org