[osg-users] [osg-submissions] API configurations in a separate Config include file

[Paul Melis]

Hi Bob,

Bob Kuehne wrote:
>> Paul Melis wrote:
>>
>> This should primarily go into the release notes. The FAQ isn't the best
>> place to store items that only apply to certain OSG versions.
>>
>> Paul
>>     
> i disagree - this change affects not just this specific version, but
> this version and *all* future versions, at least until this mechanism
> is changed again. and the reason for documenting it is that without
> some attention to how this new change operates, it appears as though
> the build is broken.
>   
Exactly. And the first place to document this is in the release notes 
that accompany 2.6 when it comes out.
We can then place an entry in the FAQ that links to these notes.
> so, i'd second the motion that this be written in both the relnotes
> and the FAQ. the relnotes/changes happen automatically from commit
> messages, 
> but the FAQ should be the place people look, instead of
> posting to the list.
>   
Yes, the list is used too much as a general knowledge base for things 
that (mostly) Robert keeps explaining over and over again. The number of 
posts on osgViewer and multiple 
views/cameras/contexts/windows/monitors/scenes/rendering targets is just 
staggering. I know osgViewer is a relatively new component, but the lack 
of some high-level overview doesn't really help. It seems there _are_ 
some pages on the wiki that try to explain aspects of the node-kit, but 
these appear a slight bit messy. Nor have I seen many people refer 
posters to these pages (perhaps for that reason).

What I suspect (I might be wrong, of course) is that the accumulated 
time spent on answering mails on this part of OSG could have been better 
used to write a single overview piece that was published at the time OSG 
2.0 came out roughly a year ago. This would have people given something 
to start with and get their minds around the concepts used and it would 
be possible to refer to that piece as "the" introductory document for 
osgViewer. I guess this is also a bit of personal preference, as I much 
prefer to read a good explanation than having to use the list.

Regards,
Paul




> b
>
> On Wed, Jun 25, 2008 at 3:26 AM, Paul Melis <paul at science.uva.nl> wrote:
>   
>> Hi Paul,
>>
>> Paul Martz wrote:
>>     
>>> I was surprised to see a change with such widespread ramifications
>>> discussed
>>> only on osg-submissions, so I'm cross-posting.
>>>
>>> I think I've now waded through enough of the posts in this thread to
>>> understand why this was done, and how to cope with the fact that OSG
>>> header
>>> files are now in the build directory.
>>>
>>> Mathias, could you take the time to enter a FAQ on the wiki regarding
>>> this?
>>>
>>>       
>>     
>>> I foresee many posts when people upgrade to the latest OSG of the form:
>>> "why
>>> can't my application find the Config header?". Users will need to know the
>>> following:
>>>
>>>  * OSG now generates headers in the build tree. If your app links with OSG
>>> from a source/build tree, your app will now need to look for headers in
>>> multiple locations.
>>>
>>>  * You can get around this by installing OSG. You can customize the
>>> install
>>> location with an OSG cmake variable.
>>>
>>>  * Any other info you think is relevant.
>>>
>>> A FAQ on the wiki would be better than having people search the
>>> osg-submissions archives.
>>>
>>> Thanks,
>>>   -Paul
>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> osg-users at lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>>       
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>     
>
>
>
>