Dirk Reiners wrote: > Hi Marcus, > > Marcus Lindblom wrote: > >> http://boost.cvs.sourceforge.net/boost/boost/boost/config/auto_link.hpp?view=markup >> >> It's a bit "boosty" but it might be possible to clean it sufficiently so >> that it's useful for everyone. Note that it has automatic version number >> handling which I find quite sexy. :) (I.e. choose if you want to link to >> a specific version or a general one.) >> > > You forgot to mention (but I suspected it anyway) that this only works on > Windows. ;) So for the rest of the world we need some other solution anyway. > I thought it would work for other platforms as well. Sorry. (I wasn't thinking windows only.. honest!)
My vote is on adding it in an SConscript then, if possible. (or making SCons scan the headers.) >> The basics seems to be working. I just need to figure out how make them >> scons-options. Shouldn't be that hard. >> >> If I get scons to work, I just might start experimenting on reducing >> compile & link times on Windows. The link times are almost obscene and >> incremental linking won't not work because there's too much object data >> to link (internal linker limit reached). The compile times are huge as >> well, mostly because every obj file is huge. >> >> I'll have to summarize previous discussings and and start a new thread >> on that later, when I have enough time to do something about it. >> > I was hoping pch would help with the compile time, but you're right, thelink > times are insane, and I'm not sure what to do about them. > I think PCH will help with link times as well, because much common code (esp base code) will only be compiled once. To improve things even more I think a split of System between FC base stuff & the scene graph part (and perhaps even more, cluster/drawable/group/shader/fileio) would also improve things. Both because parts that build on each other can more be configured with precompiled, and the link set is considerably reduced. I think linking has n^2-like characteristics. Small DLL's/exe's tend to link much faster than larger, it doesn't scale linearly.) It also makes for better structure (as it forces one-way dependencies between dll's) but I think we already are very good at this, so further splits should definitely be possible. As long as the build process for clients are easy (with autolink on windows and scons for everyone?) splitting OpenSG into more libs shouldn't be that cumbersome? We have good control over things here so I could volonteer to make it work for windows & vcproj-developers. As of now, I have not tried to build my own OpenSG app with SCons or Make, so I don't know how hard it would be to make it easy for users of those tools. Also, the fc2code program is not very intelligent about which headers to include (osgconfig.h is included in almost every file, etc). Especially including every field header for every field instance is bad. Also, checks for what parent classes include (and maybe other headers as well?) would probably improve things _alot_. fcd2code could also use external include guards (i.e. ifndef/endif around the include-statement), which are a pain to handle manually but with autogenerated code it's nothing. Basically, if things compile without an include statement, it shouldn't be there. I've found that including things "because most users including this file will probably use types in that file as well" is not a good way do to things. Using forward declarations is pretty nice. (Actually, with fcd2code you could generate forward-declarations for every lib or parts of them, so that it would be easy to keep those up-to-date.) We need to get this under control somehow, and actively work to improve the physical design. The size of an obj-file should roughly match the size of the .cpp-file (or at least the amount of functionality provided there, in terms of templates and such). Many obj files in OpenSG are 3-4 megabytes. It of course takes a lot of time to produce 750 mb of much machine code, but also to link it all together. Also, if we remove the global usage of Aspect-Ptr's in 2.0, there will be much less fcptr:s everywhere, which should also reduce template instantiations and code size. 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
