プロジェクトで使用されるライブラリのソース全体を含める必要がありますか？
プロジェクトでスタティックリンクライブラリを使用することに慣れています。これによってソリューションが重くなることはなく、より簡単に更新できます。
ただし、一部のGitHubリポジトリは、使用するライブラリのコードをソースに提供しています（この質問を提起させた例は、ラケット言語のソースコードのlibffiライブラリ 完全に採用 です）。
なぜそのような選択なのか？ GitHubでプロジェクトを公開する場合、プロジェクトでソースを使用する必要がありますか、それとも静的ライブラリの使用を検討する必要がありますか？
[〜＃〜]編集[〜＃〜]
私はこの質問をやや包括的に質問していますが、回答は使用されている対象や対象読者によって異なると思います。
質問にもう少し焦点を合わせるために、私はCで書かれた、組み込みでないプラットフォーム用のプロジェクトを見ていました。仮想マシンプロジェクト（Apache 2.0ライセンスの下）があり、MITおよびLGPLライセンスライブラリを使用しています。x86アーキテクチャをターゲットにしています。
ライブラリのソース全体をプロジェクトに配置すると、次のことが可能になります。
- 放棄された場合に備えて、ライブラリを維持および更新します。
- ライブラリを変更して、特定のプロジェクトの目標を前進させます。
- DevOps プロセスの一部として、FortifyやCoverity Preventなどのライブラリで静的コード分析ツールを実行します。
- プロジェクトの内部について開発者を教育します。
プロジェクトで使用されるライブラリのソース全体を含める必要がありますか？
コードがCで記述されている場合、コードは（通常）C標準ライブラリを使用します。 C++でコーディングされている場合は、C++標準ライブラリを使用します。通常、コードにそれらのソースコードを含める理由はありません（たとえば、Linuxでは GNU glibc ）。
そして、コードが非常に一般的なライブラリを使用している場合（Linuxでの例として libcurl と考えてください）、それらのソースコード（例：GitHubリポジトリ内のlibcurlのソース）を含めるかどうかはわかりません）コード内で実用的に意味があります。
プロジェクトでスタティックリンクライブラリを使用することに慣れています。これによってソリューションが重くなることはなく、より簡単に更新できます。
常に良いアイデアだとは思いません。
コンピュータで実行されているすべてのプロセスが静的にリンクされている場合、 共有ライブラリ がないため、総メモリ消費量が多くなります。 Linuxでは、Drepperの論文 How to write shared libraries を読んでください。したがって、静的ライブラリを使用するとユーザーのコンピュータが「重く」なります（- 仮想メモリ が非効率になるため、より多くの物理メモリが必要になるという意味で）。コードseveralプロセスによって使用されるライブラリのセグメントは、共有ライブラリの場合のみ paging によって共有できます）。
もちろん、詳細はオペレーティングシステム固有であり、対象ユーザーの専門知識に関連しています。
静的ライブラリを使用する動機は、 依存関係の地獄 と闘うことです。しかし、その核となる問題は パッケージマネージャ によって解決されるはずです。そして、ソースレベルで重要なのは [〜＃〜] api [〜＃〜] 互換性（ セマンティックバージョニング に関連）です。
ソフトウェアが [〜＃〜] lgpl [〜＃〜] ライブラリを使用する場合、パッケージ化されてバイナリ形式で再配布される可能性が低くなることにも注意してください。動的にリンクされます（これは単純化しすぎです）。
私の個人的な推奨はuse（Linuxの場合）sharedですライブラリは通常、主要なLinuxディストリビューションにパッケージ化されます。もちろん、悪は詳細にあり、マイレージは異なる場合があります。
SoftwareHeritage プロジェクトと、これらの素晴らしい人々（特に Roberto Di Cosmo ）が行っている研究に興味があるかもしれません。
私の RefPerSys および Bismon プロジェクト（どちらもGPLv3 +フリーソフトウェア）で、私は間違いなく共有ライブラリを使用しています。
私の Debian デスクトップでは、ほとんどすべてのソフトウェアが動的にリンクされていますが、それには十分な理由があります。例外には sash のような低レベルのユーティリティが含まれます。