VOICEVOX/voicevox_core

[0.16] README等のドキュメントで気になった箇所を列挙

Closed this issue · 7 comments

内容

0.16に向け、色々見ていった感じドキュメントが古くなってそうな箇所を列挙してみます。
このissueの内容は勝手に変更していただいて大丈夫です!

README

  • Releases にビルド済みのコアライブラリ(.so/.dll/.dylib)があります。 ←ドメイン用語が今と違うかも。「コアライブラリ」は.zipを指すけどたぶんなくなってる。「C API」があります、もしくは「各言語向けのAPIライブラリ」がありますとか?(ちょっと適当です)

環境構築

  • 使う人向けの環境構築なのか、貢献者向けの環境構築なのか分からなそう。多分貢献者向けガイドなので、それがわかるような見出しにすると間違えてここに迷い込む人が減るかも。

コアライブラリのビルド

  • コアライブラリという名称は古いかも。コアAPIとか?
  • cmake が必要です ←本当?
    本当。open_jtalk-rsに必要なはず
  • model フォルダにある onnx モデルのみが利用できます ←古そう
  • # DLLをビルドload-onnxruntimeでfeature合ってる?
    合ってるはず (@qryxip)
  • # ヘッダファイルを加工し、マクロVOICEVOX_LOAD_ONNXRUNTIMEを宣言 ←今もそうでしたっけ
    今もそう。リリース時にはGHA内で加工 (@qryxip)

APIドキュメント

  • TODO消してリストにしても良いかも。
  • Java APIは消しても良いかも

VOICEVOX コア ユーザーガイド

  • ダウンロードの使い方は最新?
  • exampleへのリンクがあると良いかも
  • 全体的にあってそうな気がする!けど中身確認

Downloader

  • ダウンロードするものの説明が少ないかも?

cmake が必要です ←本当?

多分cmakeがないとopen_jtalk-rsのビルドが落ちるかと。

あ、そうですね。危なかった。

readmeについて、今こういうセクション構成になっているのですが、

  • ## API
  • ## ユーザーガイド
  • ## 環境構築
    • ### Windows の場合
    • ### Linux/macOS の場合
    • <summary> Downloader を使わない場合</summary>
      • [コメントアウト] #### Raspberry Pi (armhf)の場合
    • ### 注意
    • #### GPU の使用について
      • ##### CUDA
      • ##### DirectML
      • [コメントアウト] #### Raspberry Piでの使用について
  • ## サンプル実行
    • ### その他の言語
  • ## 貢献者の方へ
    • ### Rust 以外の言語の API に関する方針
  • ## C APIのビルド
  • ## C APIライブラリのテスト
  • ## ダウンローダーの実行
  • ## ヘッダファイルの更新
  • ## タイポチェック
  • ## 事例紹介
  • ## ライセンス

一部はdocs/guide/devに隔離できると思います。

 - `## API`
 - `## ユーザーガイド`
 - `## 環境構築`
     - `### Windows の場合`
     - `### Linux/macOS の場合`
     - `<summary> Downloader を使わない場合</summary>`
         - \[コメントアウト\] `#### Raspberry Pi (armhf)の場合`
     - `### 注意`
     - `#### GPU の使用について`
         - `##### CUDA`
         - `##### DirectML`
         - \[コメントアウト\] `#### Raspberry Piでの使用について`
 - `## サンプル実行`
     - `### その他の言語`
-- `## 貢献者の方へ`
-    - `### Rust 以外の言語の API に関する方針`
-- `## C APIのビルド`
-- `## C APIライブラリのテスト`
-- `## ダウンローダーの実行`
-- `## ヘッダファイルの更新`
-- `## タイポチェック`
 - `## 事例紹介`
 - `## ライセンス`

docs/guide/userにも分離できるかもしれません。というよりusage.mdとの役割が被っているので、こっちを見てねとした方がよい気がしています。

 - `## API`
 - `## ユーザーガイド`
-- `## 環境構築`
-    - `### Windows の場合`
-    - `### Linux/macOS の場合`
-    - `<summary> Downloader を使わない場合</summary>`
-        - \[コメントアウト\] `#### Raspberry Pi (armhf)の場合`]
-    - `### 注意`
-    - `#### GPU の使用について`
-        - `##### CUDA`
-        - `##### DirectML`
-        - \[コメントアウト\] `#### Raspberry Piでの使用について`]
 - `## サンプル実行`
     - `### その他の言語`
 - `## 事例紹介`
 - `## ライセンス`

@qryxip READMEのダイエットは賛成です!
いろんなリポジトリミルに、理想的にはリードミーはポータルに近づいていくと思います。
(onnxruntimeとかそう)

各リンクや僕たちがアピールしたい分野へのリンクだけは、ちょっとだけクイックスタート的なものを書いてもいいかも。
書かなくても良さそう!
とりあえず分割には賛成です。提案も妥当そう!!

APIドキュメント

  • TODO消してリストにしても良いかも。

ちょっとここら辺がよくわかっていないのですが、VitePressのやつが順調なのであればそっちを待つということで、現状の素HTML版の方にTODOの文字を残し続けても別にいいんじゃないかとちょっと思いました。

TODO消してリストにしても良いかもの意味がよくわかんないですね。。。すいません。。。
たぶん「TODOコメントを消して、issueとしてTODOリストを作ると良いかも」という意図だったと思います 🙇

VitePressに移動するにしろ移動しないにしろ、コメントとして残し続けるのでも別に良いと思います!

こちらのタスクほとんど終わってそうですね!!! お疲れ様でした!!!
残りのタスクを一旦完了させられると管理しやすいので、さくとプルリクエスト作ってみました。
まあjava apiは後から復活するかもですが、とりあえずこれでタスクが完了するので一旦マージするのもいいのかなと。