I'm starting the process of producing packages for Ubuntu so that when the code is released it can easily be included.
Without actually building and installing 2.0 I'm planning on following the same installation paths as 1.8. libs directly in /usr/lib so they can easily be found both by the linker and users running applications. .h and .inl files will go into /usr/include/OpenSG/ so that in peoples applications they can continue to be included as <OpenSG/OSGfoo.h> However I wanted to get a few ideas of what should be produced by default. My initial thoughts are to enable everything by default, expect for: - deprecated methods and properties - only enable memory debugging on the debug version. (does this mean I have run scons twice, once for debug and once for optimized?) Is this a sane set of defaults to use? By enabling the OpenSG 1.8 compatibility option I assume the libraries can be used for both 1.8 and 2.0 code, therefore I can make the packages conflict with OpensG 1.8 so both aren't installed. -- David Morris Research Assistant School of Computing, Mathematics and Information Sciences, Room 108 Watts Building Lewes Road University of Brighton Bright BN2 4GJ UK +44 (0)1273 642917 IRC : davemorris on irc.freenode.net Jabber : david.mor...@jabber.org
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users