| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add some prose to the documentation index page to guide readers to the
major manuals and guides.
Add a new "User Interaction Guide" to help the class of new user
who wishes to build a project with CMake for the first time, such as
after cloning a repo from a git repository.
Add a new "Using Dependencies Guide" to help the class of new
user who wishes to consume a SDK provided by a third party and needs a
starting point. This is a different type of user to the user who wishes
to create their own project from scratch (addressed by the
`cmake-buildsystem(7)` manual) as each will encounter needs for
information discovery in a different order.
|
| |
|
|
|
|
|
|
| |
We removed installation of `Help/index.rst` in commit d2fde94809 (Help:
Add infrastructure for guide-level documentation, 2019-05-30), but the
file is required for `--help-full` to work. Restore installation of the
file and update it to avoid referencing the `Help/guide` directory in
its toctree during processing by `cmRST`.
|
| |
|
|
|
|
|
| |
Create a `Help/guide/` directory to hold guide-level documents.
Build them in most documentation formats, but not as man pages.
Initialize the guide directory with a placeholder for the tutorial.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a file-based API that clients may use to get semantic information
about the buildsystem that CMake generates. Clients will write query
files under a designated location in the build tree, and CMake will
write reply files for clients to read.
Start with support for shared stateless query files. These allow
clients to share requests for major object versions and get all those
recognized by CMake. Once any client has written a shared request to a
build tree it will persist. Other clients will not need to overwrite
the request (since it is stateless) and should not remove it either.
For now we add only an undocumented object kind to use for testing the
query and reply infrastructure. Object kinds providing real semantic
information will be added later.
Issue: #18398
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation for CPack generators previously lived in their
respective internal CMake modules. This setup was misleading,
because it implied that you should include the modules in your own
code, which is not the case. Moving the documentation into a
separate section does a better job of hiding the internal modules,
which are just an implementation detail. The generator documentation
has also been modified to remove any references to the module name.
The CPackIFW module is a special exception: since it has user-facing
macros, the documentation for these macros has been kept in the module
page, while all other documentation related to the IFW generator has
been moved into the new section.
To make it easier to find the new documentation, the old help pages
for the CPack*.cmake modules have not been deleted, but have been
replaced with a link to their respective help page in the new
documentation section.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Link to it from the documentation of related properties, variables
and commands.
Extend the cmake-developer(7) documentation with notes on
extending feature support for compilers.
|
| |
|
|
|
|
| |
Add a release/index.rst document titled "CMake Release Notes" to hold
the toctree for release notes. Add a "Release Notes" section to the
top-level html document index to link to the new document.
|
| |
|
|
|
|
|
|
| |
Add an introduction about the use of different package types, and the
ability to use Qt 4 and 5 versions together in a single buildsystem.
Add a section about automatic linking of the qtmain.lib library and
how to disable it.
|
| |
|
|
|
|
|
| |
Describe how to define a buildsystem of binary targets, how to
express dependencies between them, how to add build specifications,
how to specify usage requirements, transitive and compatible
propagation and the various pseudo targets.
|
| |
|
|
|
|
|
|
|
|
| |
Revise the organization introduced in commit 2c7cd95c (Help: Organize
top-level index, 2013-10-28) to drop "Other Manuals" and put them in
"Reference Manuals" because the distinction between them has blurred.
Perhaps a better breakdown of the reference manuals will emerge in
the future.
While at it, sort the reference manual toctree by name.
|
| |\
| |
| |
| |
| |
| | |
3fe4ac8 Help: Add a CMake manual for Packages related docs.
20cafa2 Split the find_dependency macro into a separate file.
|
| | | |
|
| |/
|
|
| |
Create a manual for toolchain related docs.
|
| | |
|
| |
|
|
|
| |
Add an explicit title directive to set the HTML index page title instead
of taking the first section header.
|
| |
|
|
|
| |
Divide the list of manuals into separate sections each with its own
title.
|
| |
|
|
|
| |
Add the manual with just an introduction section. Leave section headers
for Help and Modules to be filled in later.
|
| |
|
|
|
|
|
|
|
| |
Generator expressions are supported in many places and are a distinct
concept worthy of their own manual page. The old builtin documentation
was previously represented by preprocessor macros to generate it into
each place that supports them. Factor out the duplicate content into a
dedicated cmake-generator-expressions manual page and reference it from
each original location.
|
|
|
Add a top-level document holding the Sphinx root toctree. List all
reference manuals from Help/manual/*.rst and the Sphinx-generated
general index (genindex) and search pages.
|
