Hi, On Thu, 2009-07-02 at 16:55 +0200, Marcus Lindblom wrote: > Gerrit Voß wrote: > > Hi, > > > > On Thu, 2009-07-02 at 09:55 +0200, Marcus Lindblom wrote: > >> Gerrit Voß wrote: > >> > >>> If you have anything else let me know. One open issue is custom > >>> compiler flags. > >>> > >>> I'm also not sure all the 3rd party libs are handled correctly for > >>> all variants. I'll try to check this but it will take a second as > >>> windows builds are so slow ;( And I have to build the 3rd party > >>> lib variants ;( > >> We/I need to reduce the #include-hogging for that. > > > > jep, but I still don't have a really good idea for that. > > > > We did the simple approach with scons but that confused the hell out of > > debuggers and me when I again edited the wrong file just to find > > it overridden after the next build ;( > > I was thinking about removing unnecessary #includes in .h files and > reduce code in .inl. F.ex, the fcdcompile script #includes some files > many times, both in the current class _and_ if the superclass has the > same field types.
yes, the n-time include the same annoyed me too. With the superclass I'm not sure (automatically) as usually the fcd progs only see the current .fcd file, not the parent's one, so that maybe needs some hints in the fcd files. > More pimpling or just fwd-declare and less inline might also help. Hmm I would more tend to just forward declare and less inline. But that has a limit, in the container world a lot of includes come from the fact that the ptr fields need to have to access the container for the ref counting so you have to include the class declaration in case you inline the set/get methods, there are also some downcasts involved IIRC. As the big blocks of code come from templates rather that the container classes I'm not sure if you can completely get rid of them. I'll have a look. Pimpl, I'm not sure we already have tons of classes and it adds another indirection. And changing the design for one platform is always something I'm not to happy about. > However, the big win is probably pch support. I'll have to look at that. Ok that would be great, I never worked with them, neither on windows nor on linux so I don't really have a good idea what they require. > >> I'll keep an eye open when it's time to compile. :) > >> > >> Note that for third-party libs, we don't really need all those variants > >> there. Just something built against debug/release runtimes. It's more a > >> matter when debugging against OpenSG itself that these additional > >> variants are useful. > > > > currently it only builds Debug/Release. Maybe we could switch > > Debug to DebugOpt, but at least once I had to debug 3rd party > > stuff (collada) because either collada itself or libxml2 was > > buggy, forgot the details already ;). > > Yeah. I think we need Debug for times when things go real bad. DebugOpt > is nice to have as some parts of the app runs faster in debug. We can > perhaps wait and see where performance problems during debugopt-running > occur and add support for recompilation of those libs. sounds reasonable. As the compiler settings from OpenSG are directly included adding any of the other targets should not be a problem. kind regards, gerrit ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
