Hello Gerrit,
I just glanced through the OpenSG options in the CMakeLists.txt file. I
do not understand all of the options. I can guess the meaning of some
but not all. Additionally, I do not know the consequences on
enabling/disabling of some options. Some options seems to be only
primarily, some are for special purposes, etc. Overall we are getting
more options not less.
I would like to propose that we do the following:
1. Explicitly partitioning of the options into categories, for example:
a) What is being build: Test, Examples, Python,
Documentation...
b) How it is build, i.e. ABI related stuff, sse2,..
c) Packaging support
d) Debugging support
e) Platform: e.g. OSG_ENABLE_OGL_COREONLY
f) Features: e.g. OSG_ENABLE_NEW_OSB_IO
g) Experimental, Temporary: e.g.
OSG_ENABLE_MULTISHADER_VARCHUNK
h) Environment: e.g. OSG_ENABLE_GL_INCLUDE_GLEW
i) Internal: e.g. OSG_ENABLE_FCD2CODE
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
To be clear, this is not a critique on the build system at all. I only
wish to clarify and simplify the optional build space of OpenSG.
What do you think?
Do you like the idea of in place documentation in the CMakeLists.txt
file?
Best,
Johannes
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
