-
Notifications
You must be signed in to change notification settings - Fork 604
docs: unify user journey and clarify build and early deployment flow #7806
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
docs: unify user journey and clarify build and early deployment flow #7806
Conversation
|
Thanks for the review. I’ve applied all the suggested clarifications, fixed stale Doxygen references, and ensured the docs build cleanly. Please let me know if anything else needs tweaking. |
| - INTERNAL = for DynamoRIO developer use | ||
| - DISABLE_WARNINGS = useful if your version of gcc produces warnings we have not seen (we compile with warnings-are-errors) | ||
|
|
||
| \subsubsection sec_cmake_debug Debug Build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is now splitting up the CMake text: see line 638 which says "Press Configure" and shouldn't be under a Debug Build header. This debug section would have to be further down; it's not until https://dynamorio.org/page_building.html#autotoc_md102 where it says you can pass parameters on the command line.
Maybe it should go back up under Advanced Build Scenarios?
This PR refines the structure and navigation of the DynamoRIO documentation by establishing a canonical end-to-end User Journey on the home page and aligning the build and deployment guides with that flow.
The build documentation is reorganized to clearly separate quick-start guidance from advanced build scenarios, and to explicitly document build layout, install outputs, and platform/architecture scope. Runtime validation steps are removed from the build flow to keep build and execution concerns distinct.
The deployment documentation adds concise execution context, including where
drruncomes from, how the launch models differ (drrun,drconfig,drinject), and what constitutes a first successful run. Platform-specific deployment content (Android, QEMU) is grouped under an advanced section, and attach behavior is consistently marked as experimental.The Build Your Own Tool page is kept focused on client APIs and concepts, with a short reference to the canonical User Journey rather than duplicating workflow steps.
Documentation only; no API, tooling, or behavioral changes are introduced.