Dirk Reiners wrote: > Hi Marcus, > > Marcus Lindblom wrote: > >> Yup. Changing fcd2code so that it generates external include guards >> should be quite easy, and helpful, in terms of compilation perf. >> > > I don't know. Has anybody run those kinds of tests with 2005? The gcc results > indicate that it's very possible to make external and internal ones perform > equally well, so MS might have done the same thing. > Gcc usually runs under filesystems with different performance as well. The only thing I know is that when I precompiled some headers for my FBO-viewport, things went a lot faster. Usually, avoiding includes is a good thing. OpenSG includes files like no other API I've ever seen (not that my experience is that large). My main issue is that there does not seem to be _any_ thought given to reduce the amount of includes, the issue has been practically ignored, which IMHO is not that good for such large pieces of C++ software. >> I have also been toying with the idea of rewriting the >> #include-statements in OpenSG to use a path with dirs relative to the >> source-directory. That'd make the compiler only have one root include >> path for OpenSG-libs, and since we're rewriting the include-files on >> export anyway, it's not a problem to have a single include-dir for end >> users as we do today. >> > > > >> It'd also make the build scripts a tiny bit simpler since you don't need >> to add all those include-paths. The output would be reduced. (Each >> compiled file in system takes up almost half a screen of text currently.) >> >> Does it sound reasonable? >> > > That's the way 2 is anyway, to reflect the installation structure already > during > build. Given that you get a direectory with lots of files it might not have a > positive impact on performance, but the compile lines sure looks nicer. ;) >
I was thinking the other way around, that you'd always use the source structure. I.e. include '/system/nodecores/drawables/geoemtry/base/osggeobuilder.h' and always do that. Of course, you'd need to make the source directories a bit more coherent than today (I find them a bit confusiing) but that could serve to provide some sort of namespacing etc. I agree with Gerritt that source-rewriting tricks such as massive sed-ing isn't really a good thing. It tends to misbehave every now and then and when it does, you get quite upset. So far, I always copy the entire include-lib when I update OpenSG, and I have to recompile my app from scratch, so I tend not to do that very often. I don't really see how I can set things up today so that I can use the OpenSG checkout-directory directly. And having old header files laying around is dangerous. But as Gerritt said, is not a huge issue, yet. It's just another small one in the way of contributing efficiently to OpenSG. Cheers, /Marcus ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
