[backport 1.1] doxygen: use CMake build dir intead of source dir to host generated files#760
[backport 1.1] doxygen: use CMake build dir intead of source dir to host generated files#760valeriosetti wants to merge 8 commits intoMbed-TLS:tf-psa-crypto-1.1from
Conversation
…iles Signed-off-by: Valerio Setti <vsetti@baylibre.com>
…Crypto Signed-off-by: Valerio Setti <vsetti@baylibre.com>
"apidoc" is now built into the Cmake's build directory and not in the source tree. While at it also remove references to "apidoc/topic.html" because the file is not generated as part of "tfpsacrypto-apidoc" target build. Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
…tespaces Signed-off-by: Valerio Setti <vsetti@baylibre.com>
bjwtaylor
left a comment
There was a problem hiding this comment.
Do we need to update framework/scripts/apidoc_full.sh:58, there appears to be at least a stale comment here. Though not sure if can just be removed or if there is a bigger issue?
Thanks to this comment I made a quick comparison with what's being done in the
Point (2) suggest that:
|
gilles-peskine-arm
left a comment
There was a problem hiding this comment.
This is a technically correct backport of #718. However, I'm not sure it's an acceptable change in an LTS branch.
IIRC you suggested creating an apidoc symlink in the source tree, I think that would be an acceptable compromise (doing nothing if apidoc is an existing directory). (Although that doesn't work on Windows.)
So just to be sure I understood correctly: the symlink should be done only for the LTS or also for |
|
We don't have firm rules around build system changes. I think it's ok to keep things simple in the development branch, but I'm uncomfortable with changing the interface for the build of the documentation in an LTS branch. So my opinion is symlink in LTS, no symlink in development. But others may have a different opinion. |
Add a new CMake's custom command that's executed after apidoc is built. It places an in-tree symlink to the 'apidoc' folder in the binary directory. While at it also update the changelog note about this improvement. Signed-off-by: Valerio Setti <vsetti@baylibre.com>
gilles-peskine-arm
left a comment
There was a problem hiding this comment.
LGTM except for in-tree builds
|
|
||
| # Create an in-tree symlink to the apidoc built in the binary folder. This is | ||
| # only performed on Unix platforms and if "apidoc" doesn't exist in-tree. | ||
| if(UNIX AND NOT EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/apidoc) |
There was a problem hiding this comment.
This checks for the existence of apidoc when you run cmake, not when you build the documentation.
One consequence is that if you do an in-tree build from a fresh checkout, cmake decides that you do want to create apidoc, but then it fails because that's an existing directory.
So at least this part should be skipped if the source tree is the build tree.
Furthermore, if you do an in-tree build after an out-of-tree build, the out-of-tree build overwrites the apidoc in the out-of-tree build. Admittedly that would be pretty unusual (I guess most users either do an in-tree build or one or more out-of-tree builds but not both), but it's definitely not desirable behavior.
Also, if you do two out-of-tree builds, which one will “win” apidoc depends on whether you do cmake -B dir1; make -C dir1; cmake -B dir2; make -C dir2 or cmake -B dir1; cmake -B dir2; make -B dir1; make -B dir2. This isn't wrong (only one build can win and there's no particular reason to prefer a specific one), but it's weird.
| directory. | ||
| Fixes #381. |
There was a problem hiding this comment.
Minor:
| directory. | |
| Fixes #381. | |
| directory. Fixes #381. |
Signed-off-by: Valerio Setti <vsetti@baylibre.com>
- only create when doing an out-of-tree build. - evaluate if the symlink is to be created at runtime. In case of multiple successive build, only the first one will create the symlink. Signed-off-by: Valerio Setti <vsetti@baylibre.com>
Description
Backport of #718. Resolves #381.
PR checklist