Hi Lars,
On Mon, 2005-01-24 at 11:43, Lars Hillebrand wrote:
> Hi Dirk
>
> Just as an info:
> Today i put a beginEditCP()/endEditCP() around each setValue, but
> without any success. Previouly i had only one pair of this around the
> whole build.
That shouldn't matter. In fact, it's better to do one around evetything
(as long as you don't forget anything ;).
> I am using Gentoo-Linux with Kernel 2.6.10, gcc 3.3.5, latest ATI-Drivers.
Should be fine.
> Thats no Problem.
>
> I will send it to you and Gerrit only, i dont think that everybody on
> this list has use for it.
I took an initial look at it and fixed some problems (see separate
mail), I just have some general style comments on it that I've seen
before and that might be interesting for more people.
I've seen people have both <OpenSGBase>/include as well as
<OpenSGBase>/include/OpenSG in their include paths.
The reason that becomes necessary is because they create code for their
new classes using fcdEdit and when they try to compile they errors about
not being able to include files like <OSGConfig.h>. The (perceived)
simplest solution is to just add include/OpenSG to the include path.
The real solution is set System Component to false, if you don't put
your new class into the system but into your own app. Depending on
whether you are deriving from a system component, set the Parent System
Component to false or true, most of the time it will be true.
Explanation:
The reason these files are sought is that there are two different
include conventions for OpenSG. One is the one used inside the lib's
source code. The headers are located together with the source files
(which IMHO simplifies working with them significantly), and each source
directory is adding to the include path by the build system
automatically, so they don't need the OpenSG/ prefix. The other is used
for an installed library, where all the header files are copied together
into one directory, which for reasons of filespace pollution is not
<OpenSGBase>/include but <OpenSGBase>/include/OpenSG. To make the
headers compatible during the install process the OpenSG/ prefix is
added to all #include statements.
So does that comes into play for your own code? fcdEdit can generate
code for system-internal components (which use the <OSGConfig.h>
convention) and for components that are not under the control of
OpenSG's build system (which use <OpenSG/OSGConfig.h>). That's that the
"System Component" toggles in fcdEdit (or the systemComponent fields in
.fcd) are for. The two classes that matter in this respect are the
actual new class and its parent class (which also needs to be included).
Thus you can specify separately, whether the new class is a system
component and whether its parent is a system component.
Hope it helps
Dirk
-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
