トラブルシューティング

既知の問題

  • Doxygenは真のコンパイラではなく、単なる字句スキャナーです。つまり、ソースコード内のエラーを検出することはできませんし、しません。
  • Doxygenには組み込みのプリプロセッサがありますが、これはCプリプロセッサとは少し動作が異なります。Doxygenは、ヘッダーファイルが多重インクルードから適切に保護されており、各インクルードファイルがスタンドアロンである(つまり、コンパイラエラーを引き起こすことなくソースファイルの先頭に配置できる)と仮定しています。これが真である限り(これは良い設計習慣です)、問題に遭遇することはないはずです。
  • 考えられるすべてのコードフラグメントをテストすることは不可能であるため、一部の有効なC/C++コードが適切に処理されない可能性が十分にあります。そのような部分を見つけた場合は、Doxygenの解析能力を向上させられるよう、私に送ってください。検索範囲を絞り込むのに役立つよう、送っていただくコードは可能な限り小さくしてください。
  • Doxygenは、コード内に同じ名前の複数のクラス、構造体、または共用体がある場合、適切に動作しません。しかし、クラッシュするのではなく、同じ名前のクラスのうち1つを除くすべてを無視するはずです。
  • 一部のコマンドは、他のコマンドの引数内では動作しません。たとえば、HTMLリンク(つまり、<A HREF="...">...</A>)内では、他のコマンド(他のHTMLコマンドを含む)は動作しません!セクション化コマンドは重要な例外です。
  • 冗長な中括弧は、場合によってはDoxygenを混乱させる可能性があります。たとえば
      void f (int);
    
    は関数宣言として適切に解析されますが、
      const int (a);
    
    も、セマンティクスではなく構文のみが解析されるため、名前がintの関数宣言と見なされます。冗長な中括弧が次のように検出できる場合
      int *(a[20]);
    
    Doxygenは中括弧を削除し、結果を正しく解析します。
  • ドキュメントに含まれるコードフラグメント内のすべての名前がリンクに置き換えられるわけではありません(たとえば、SOURCE_BROWSER = YESを使用している場合)。また、オーバーロードされたメンバーへのリンクが間違ったメンバーを指す場合があります。これは、各関数に対して生成される「Referenced by」リストにも当てはまります。

    この理由の一部は、現在のコードパーサーが十分にスマートではないためです。将来的には改善に努めます。しかし、これらの改善をもってしても、あいまいさの可能性や、コードフラグメントが見つかったコンテキストに関する情報不足のため、すべてを対応するドキュメントに適切にリンクできるわけではありません。

  • クラスAにすでにfという名前で同じ引数リストを持つメンバーがある場合、\relatesまたは\relatesalsoコマンドを使用して、非メンバー関数fをクラスAに挿入することはできません。
  • 現在、メンバーの特殊化に対するサポートは非常に限られています。特殊化されたテンプレートクラスがある場合にのみ機能します。
  • すべての特殊コマンドがRTFに適切に翻訳されるわけではありません。
  • dotのバージョン1.8.6(およびそれ以前のバージョンも)は適切なマップファイルを生成しないため、Doxygenが生成するグラフが適切にクリック可能になりません。
  • PHPのみ:Doxygenは、すべてのPHPステートメント(つまりコード)が関数/メソッド内にラップされていることを要求します。そうでない場合、解析問題に遭遇する可能性があります。

協力方法

Doxygenの開発は皆様からの入力に大きく依存しています!

Doxygenを試す場合は、ご意見をお聞かせください(不足している機能はありますか?)。使用しないと決めた場合でも、その理由をお知らせください。

バグの報告方法

バグはGitHubの課題トラッカーで追跡されています。新しいバグを提出する前に、まず他のユーザーによって同じバグがすでに提出されていないかデータベースを検索してください。新しいバグを発見したと思われる場合は、報告してください

何かがバグであるかどうか不明な場合は、まずユーザーメーリングリスト(購読が必要です)またはStack Overflowdoxygenタグを使用して助けを求めてください。

バグの(漠然とした)説明だけを送っても、通常はあまり役に立たず、私があなたの意図を理解するのにずっと時間がかかります。最悪の場合、あなたのバグ報告は私に完全に無視される可能性さえあるため、常に以下の情報をバグ報告に含めるようにしてください

  • 使用しているDoxygenのバージョン(たとえば1.5.3。不明な場合はdoxygen --version、さらに詳しい情報が必要な場合はdoxygen --Versionを使用)。
  • オペレーティングシステムの名前とバージョン番号(たとえばUbuntu Linux 18.04 LTS)
  • 通常、設定ファイルも一緒に送るのが良いですが、ファイルを小さく保つために、生成時にはDoxygenを-sフラグ付きで使用してください(既存の設定ファイルからコメントを削除するにはdoxygen -s -u [configName]を使用します)。さらに良いのは、使用されている設定とDoxygenのデフォルト設定との違いを取得するために、使用されている[configName]-xまたは-x_noenvフラグを使用することです(例:doxygen -x [configName])。
  • バグを修正するための最も簡単(そしてしばしば唯一の)方法は、問題を再現できるように、問題を実証する小さな例をバグ報告に添付していただくことです。例が有効なソースコード(コンパイル可能である可能性のある)であり、問題が本当にその例で捉えられていることを確認してください(実際のバグを引き起こさない例を受け取ることがよくあります!)。複数のファイルを送る場合は、処理を容易にするためにファイルをzipまたはtarで1つのファイルにまとめてください。新しいバグを報告する際、最初のバグ説明を提出した**後**にのみファイルを添付する機会が得られることに注意してください。
  • 提出する前に、いくつかのデバッグフラグでDoxygenを実行することも検討してください。すべてのフラグについてはdoxygen -dを実行してください。preprocessorオプションは、Doxygenが入力ファイルをどのように解釈しているかについてヒントを与えるかもしれません。

報告されたバグのパッチを追加できます(強く推奨します)。その場合、プルリクエストフォームのタイトルとして「issue #NUMBER TITLE」を使用してください。「NUMBER」と「TITLE」は、GitHubの関連する課題を指します。

既存のバグや制限を修正する方法についてアイデアがある場合は、開発者メーリングリスト(購読が必要です)で議論してください。バグトラッカーやメーリングリストを介して送信したくない場合は、doxyg.nosp@m.en@g.nosp@m.mail..nosp@m.comに直接パッチを送信することもできます。

パッチについては、「diff -uN」を使用するか、変更したファイルを添付してください。複数のファイルを送る場合は、すべてをtarまたはzipで圧縮してください。そうすれば、私が保存してダウンロードするファイルは1つだけになります。

次のセクションに進むか、インデックスに戻ります。