質問

C ++を知っている人は、「Unity Build」が意味するのを知っているかもしれません:

  1. *。プロジェクトのCPPファイルはすべて効果的に supermassiveソースファイル #includeディレクティブに指定されています。 * .hppと* .hファイル
  2. このソースファイルはコンパイラに入力されています
  3. 仕上げ!あなたは出力バイナリを得る!

    これを行うこのようにして、中間ファイル(* .o)が少ないこと、ファイルの読み取りやディスクIOのオーバーヘッドが少なくなること、コンパイラの呼び出しが少なく、ビルドパフォーマンスが向上します。

    私の質問は、これがラテックスのためのこの可能性がありますか? PDFlateXを使用して最後の.pdfを構築する前に、遅い後処理パスがあります。現在、.texファイルの私の成長リストを処理するのに約7秒かかります。このパスを実行する one ファイルを実行していると私は信じています。これは私の質問をやる気にさせます!

    要約する、私はを望みます

    1. ' merge 'すべての.texファイルは、 \ input {}と\ include {} 各.TEXファイルのマクロ
    2. スーパーマッスバイトのソースファイルを遅い後処理パス(実際にはOTT Tex-Filter、FYI)に送ります。
    3. 出力をまっすぐにパイプして pdflatex
    4. 仕上げ!出力PDFファイルを入手します。

      最初のステップはここでの問題です。任意のアイデアを歓迎します。このステップを実行するために自分のスクリプトを書く必要がない場合は最善です!

      多くの感謝!

役に立ちましたか?

解決

A good tool that can handle this is rubber, with the help of its combine module. It will gather all dependencies, and produce a single file ready for consumption.

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top