ToDo: CWE Development Documentation

[rarified]

I like maps. Maybe that's one of the things about the Myst franchise that kept my interest. I couldn't get very far without either sketching my own maps or using one someone else drew up.

When confronted by 1.2+ Mil lines of new code to explore, I want to create a road map, preferably mechanically if possible. I'll do this even before pushing the "Build" button and closing my eyes, hoping for the best.

With that in mind (along with tender fingers from cooking this last night) I present a first cut at Doxygen generated documentation for CWE at http://foundry.openuru.org/assets/CWE/d ... index.html. (X-project decoder ring required )

From casual browsing, it looks like once upon a time, the plasma code was commented with Doxygen directives that really improve the ability to navigate and understand what's going on (see the class plPhysicCoreComponent as an example). But most of the python and recent C++ doesn't continue that convention, so things are a little dry.

Derived artifacts and packages such as this will eventually be built through Hudson, on demand from changes in source repositories. This time I did it by hand to confirm the procedures. I'm still thinking about how to provide a easy way to navigate to the constructed data. Hudson gives me a link to be able to browse the artifacts of the most recent build. Should that be referenced at the top level from the OU Wiki in a section on CWE?

If you have favorite reverse-engineering processing you would like to experiment with against the CWE code base, let me know and I'll try to set it up at the foundry.

_R

[JWPlatt]

Holy Documentation, Batman!

This kind of documentation is exactly one of the things I've been very concerned about getting solved. It's right there on my unpublished ToDo list, which I hope to organize and post this week here and to JIRA. I really had no idea what there was to work with regarding docs, other than Mark saying, "What documentation?" and code being self-documenting - heh. I just knew I wanted to see versioned, full development documentation like what you have with Doxygen there. Under my developer hat, this is really exciting to see. I'd also like to see full discussion/remarks for every namespace, class, method, member, enumeration, etc., etc. That can come later, but if we have a fully implemented template for open source developers to flesh out, that's great. I'd like to see integrated documentation that provides for web browsing on the Foundry, wiki (need a template?), PDF downloads and even Visual Studio intellisense and help integration.

For the Baseline build, we don't have to be responsible for getting any of this going other than offering what we already have on whatever source that's buildable. The development community can get going with this really great head start. So ongoing, documentation is not a blocker, but we can keep it in mind and make an effort as things move along. The Baseline (default) build should be locked to build fixes only (existing bugs can wait) with the goal being able to reproduce the client and plugin under the latest version of 3ds max. For the purpose, completing Doxygen directives can be considered a fix.

As I was just about to create a topic with this in mind, I've change the title of this topic.