Page MenuHomePhabricator

Documentation build process is broken if doc target has been build
Closed, ResolvedPublic

Description

To reproduce:

Do a clean superbuild (activating all the help page related cmake variables)
Start application

-> All existing plugin documentation can be accessed via the Help Perspective

Close application
Build doc target

Build Application target
Start application

-> The help perspective features only the blueberry logging plugin

So far I have found no way to reverse the process.

Event Timeline

Marco reproduced it on linux, the correct way to reproduce is:

Do a clean superbuild (activating all the help page related cmake variables)
Start application

-> All existing plugin documentation can be accessed via the Help Perspective

Close application

Build doc target
Run CMake
Build Application target

Start application

-> The help perspective features only the blueberry logging plugin

To reverse the process:

Delete all *.tag and *.qch files in your build directory.
Run CMake
Build Application target

Start Application
-> All entries are back

Due to the fact you always have to run CMake first, I assume it is an tag file related bug...

Before building the doc target, the following files do not exist:

BlueBerry.tag
MITK.tag
MITK-$HASH$.qch

A comparison of the org_mitk_gui_qt_basicimageprocessing.tag before and after building the doc target:

Before:

<?xml version='1.0' encoding='ISO-8859-1' standalone='yes' ?>
<tagfile>

<compound kind="page">
  <name>org_mitk_views_basicimageprocessing</name>
  <title>The Basic Image Processing Plugin</title>
  <filename>org_mitk_views_basicimageprocessing</filename>
  <docanchor file="org_mitk_views_basicimageprocessing">QmitkBasicImageProcessingUserManualSummary</docanchor>
  <docanchor file="org_mitk_views_basicimageprocessing">QmitkBasicImageProcessingUserManualDetails</docanchor>
  <docanchor file="org_mitk_views_basicimageprocessing">QmitkBasicImageProcessingUserManualOverview</docanchor>
  <docanchor file="org_mitk_views_basicimageprocessing">QmitkBasicImageProcessingUserManualFilters</docanchor>
  <docanchor file="org_mitk_views_basicimageprocessing">QmitkBasicImageProcessingUserManualUsage</docanchor>
  <docanchor file="org_mitk_views_basicimageprocessing">QmitkBasicImageProcessingUserManualTrouble</docanchor>
</compound>

</tagfile>

After:

<?xml version='1.0' encoding='ISO-8859-1' standalone='yes' ?>
<tagfile>
</tagfile>

Did workflow as described in Comment 1:

In Documentation/doxygen.conf.in

  1. Removed "TAGFILES = @BLUEBERRY_DOXYGEN_TAGFILE@"

Result:
BlueBerry.tag was not build, MITK.tag was. Documentation was broken

  1. Removed "GENERATE_TAGFILE = @MITK_DOXYGEN_TAGFILE_NAME@"

Result:
Neither BlueBerry.tag nor MITk.tag was build, Documentation worked

By editing the doxygen.conf of the plugin (in the binary tree) I could enable the basicimageprocessing help.

Removed
TAGFILES = PATHtoMITK/MITK-superbuild/MITK-build/Documentation/Doxygen/MITK.tag=http://docs.mitk.org/nightly-qt4/

Will try some other settings as well.

Loading the plugins doxygen.conf in the doxywizard and running it will result in a broken tagfile, even if building with MITK will not.

(In reply to comment #7)

Loading the plugins doxygen.conf in the doxywizard and running it will
result in a broken tagfile, even if building with MITK will not.

Again a victim of doxygen not refreshing the config file. Always remember to reload the file in the doxygen wizard after changing something.

<compound kind="page">

  <name>org_mitk_views_basicimageprocessing</name>
  <title>The Basic Image Processing Plugin</title>
  <filename>org_mitk_views_basicimageprocessing</filename>
  <docanchor file="org_mitk_views_basicimageprocessing">QmitkBasicImageProcessingUserManualSummary</docanchor>
  <docanchor file="org_mitk_views_basicimageprocessing">QmitkBasicImageProcessingUserManualDetails</docanchor>
  <docanchor file="org_mitk_views_basicimageprocessing">QmitkBasicImageProcessingUserManualOverview</docanchor>
  <docanchor file="org_mitk_views_basicimageprocessing">QmitkBasicImageProcessingUserManualFilters</docanchor>
  <docanchor file="org_mitk_views_basicimageprocessing">QmitkBasicImageProcessingUserManualUsage</docanchor>
  <docanchor file="org_mitk_views_basicimageprocessing">QmitkBasicImageProcessingUserManualTrouble</docanchor>
</compound>

is already contained in MITK.tag, most likely this is why doxygen believes there to be no need to generate all of it again.

(In reply to comment #9)

<compound kind="page">
...

</compound>

All other things being equal removal of the above resulted in the manual showing up again. I have not yet been able to find a solution for a subproject already included in a tagfile creating its own referencing the encompassing one.

Currently I see several approaches I will try:

  1. Removing the plugins directories from the MITK.tag. -> This will probably result in them being removed from the online help as well. So not desirable.
  2. Not handing the MITK.tag through to the bundles. -> As far as I can tell this should work, as the plugins should not in fact reference anything in the MITK class documentation. Instead they might want to reference other plugins and their tagfiles could still be handed through.

I will test the second option.

New remote branch pushed: bug-13146-doc-build-breaks-qt-documentation

Option 2 seems to work, see above branch.

Build the html documentation and linking worked fine from there. I will merge this in the master as I do not see a need to reference any documentation in the user manuals but the one provided by dependet upon plugins.

This bug can be reopened for discussion, if this behaviour is deemed undesirable.

[29bd89]: Merge branch 'bug-13146-doc-build-breaks-qt-documentation'

Merged commits:

2012-10-24 18:35:52 Caspar Goch [d1c388]
Plugins do not need the MITK tag file, as they will only reference other plugins