Hello Carsten, On 18.02.2013 23:36, Carsten Neumann wrote:
> looks like a good starting point to me. I'd suggest trying to keep the > number of categories as small as possible, that would make it simpler to > place new options in the correct category. Along those lines: perhaps > merge Experimental in Internal into just Internal? > They are semantically different. Experimental options are options which will either move into another category or vanish on the long term. Internal options, however, are those that we need for driving the build system like the code generation process. But you are right that the number of categories should be reasonably low. >> 2. Document the categories >> >> 3. Document the options: Its purpose and relevance as well as its >> overall effect. >> >> 4. Provide value ranges for non boolean options: e.g. >> OSG_SHADER_CACHE_MODE > > IIRC this particular one exists/existed to allow Gerrit to do > performance testing and should now default to what he determined to be > the optimal setting ;) > That is of course specific to this variable, in general I agree with > your plan :) > Great. Looking for Gerrit's opinion. >> >> Do you like the idea of in place documentation in the CMakeLists.txt >> file? > > yes, that way it is where the variables/options are defined, so has a > higher chance of being updated. > Imho, it would be an enhancement. I found myself looking into the implementation to get first hand information about the details of some options. And sometimes that neither did help. Best, Johannes ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
