パッケージとともに外部プログラムを提供する適切なアプローチ

私は、使用する外部プログラムをインストールできることで恩恵を受ける多くのelispパッケージ（codesearch、emacs-ycmd、traadなど）を維持し、一部のユーザーの時間と労力を節約しています。たとえば、codesearch.elを使用すると、ユーザー向けにコード検索ツール（elispではなくgoで記述）をダウンロード、コンパイル、インストールできると便利です。これにより、パッケージを使用するための少なくとも1つの障壁が削除されます。

これを行うための「ベストプラクティス」はありますか？たとえば、外部プログラムはどこに置くべきですか？

直接的なアドバイスがない場合は、このようなことをする（理想的にはうまくいく）パッケージを紹介してもらえますか？

package package-development

— アビンガム
ソース

ユーザーのEmacs OSがLinux、Windows、またはMac OSをブートローダーとして使用するかどうかを制御できないことを考えると、非常に困難と不可能の間のどこかにあるのではないかと思います;-)。

— mbork 14年

最大限の柔軟性を得るために、外部プログラムをEmacsパッケージから分離する方が良いと思います。外部ソフトウェアにEmacsパッケージを提供するアプローチは、含まれるRuby / Python / TeX / ...ファイルが解釈されるようなものに最適です。システムのパッケージマネージャー（muやnotmuch doなど）を介してインストールされたパッケージをEmacs Lispコードに提供する反対のアプローチは、オートロードができないため柔軟性が低くなります。

— wasamasa

二人は正しいようです。外部依存関係を提供するemacsパッケージの例は、jepaのみです。jediは、elpaパッケージにいくつかのpythonスクリプトをバンドルしています。

— アビンガム14年

これはEmacs 25でダイナミックロードを使用して実行できることですか？

— wdkrnls 14年

回答:

そのための「ベストプラクティス」はありません。それに対する既存のサポートもありません。パッケージFoo専用にインストールされている場合、インストールする場所はパッケージFooのディレクトリ内にあると思います。

その方法については、ElispパッケージがELPAを介してインストールされていると仮定して、メインのElispファイルに次のようなものを追加してみてください。

(eval-when-compile (call-process "make"))

そして、適切なMakefileを提供します。もちろん、「ほとんどの」プラットフォームで機能するには、もう少し洗練されたものが必要になるでしょう。

— ステファン
ソース

パッケージをインストールするためのel-getレシピの提供を検討することをお勧めします。

情報ファイルのセクション9「レシピの作成」を参照してください。

:build/system-type異なるプラットフォーム間で要件が異なる場合、この機能は特に重要です。詳細については、セクション9.5「ビルド」を参照してください。

— phils
ソース