我在哪里放置项目的makefile? [英] Where do I place the makefile of a project?

问题描述

假定项目目录包含子目录，例如src，bin，lib，doc等.我将项目的makefile放在哪里?

例如

• 某些项目将其makefile放在项目根目录的src/子目录中，

• 某些项目将其makefile放在项目的根目录中.

第二种感觉对我来说更具逻辑性.您是否可以提供出于某些原因将makefile放在根目录，src/或其他目录中的情况?

解决方案

剩下的问题是基于意见的，而最后一部分则是基于意见的:

您能提供一些案例，说明出于什么原因最好将makefile放在根目录，src/或其他目录中的原因?

首先，该目​​录可能不会被称为src/，但会以其他一些方式被命名.

有时Makefile本身是生成的(例如，通过 cmake 或 ISA ，还可以访问 ABI .因此，您最终可能会将目标文件和可执行文件放在一个长命名的目录中，例如obj-x86_64-linux-optimized和obj-PowerPC-AIX-debug.顺便说一句，src/目录甚至可以在多台机器上共享(例如，安装的 NFS )，只读(例如，可由多个用户共享).

请注意 GCC 需要要构建源代码在某种意义上具有不同的含义make(实际上，适用于 GCC 之类的编译器)和开发人员.

(开发人员使用的)源代码的社会定义是:人类开发人员在其上工作的程序的首选形式(您会发现该定义表达得很清楚.通过自由软件运动).

对于 GCC 或翻译单位作为编译器的输入(由gcc编译器作为 input 处理的.c和.h文件).在许多(但不是全部)情况下，此类C文件是真正的源代码，因为人类开发人员可以编写它们.

在某些情况下，会生成 生成C或C ++源"文件(如gcc或g++或clang或clang++所示)(在这种情况下，对于开发人员而言)它们不再是源代码，但对于gcc来说，它们仍然是输入源).一个经典的例子当然是 bison 生成的C文件.有关该想法的一般性讨论，请参见此我的答案.

另一个示例(其中C文件位于某个公共目录中)由特定于域(或高级)的语言实现给出 Bigloo ，鸡肉计划，我的旧 bootstrapped 时，您确实希望将生成的C文件保存在一起，也许放在某个src/目录(或某个generated/目录)中.您甚至可以将它们放在您的版本控制系统下(例如 git )，特别是对于具有单一实现的语言(否则，您将无法构建这样的编译器；您需要生成的C代码来构建它，然后再将其自身重新编译)，并且您肯定会在源 tarball .

最后，成千上万的C或C ++-或Ocaml-文件的大型项目(甚至完全是人工编写的)倾向于将这些文件分组在子目录中，特别是因为成千上万的*.c文件的单个大目录不是可读"(对人类友好).

相反，对于一个在几十个C源文件中最多包含十万行代码的小型项目，并以手动编写为Makefile，您最好将所有&包含Makefile的目录中的.h个文件.

但是是否具有某些src/目录，或者是否将编译器生成的目标文件放置在包含源文件或Makefile的同一目录中，是在很大程度上仍然涉及品味，观点，惯例和习惯.我建议在免费软件中研究现有实践. github 或其他位置上的项目(类似于您的项目).

Assume the directory of a project contains subdirectories such as src, bin, lib, doc, etc. Where do I put the makefile of a project?

For example,

• some projects put their makefile in src/ subdirectory of the root directories of the projects,

• some projects put their makefiles in the root directory of the project.

The second way feels more logically organized to me. Can you provide cases when it is better to put makefile in the root directory, src/ or some other directory for what reasons?

解决方案

The rest of the question is opinion based, but the last part is much less opinion based:

Can you provide cases when it is better to put makefile in the root directory, src/ or some other directory for what reasons?

First, that directory might not be called src/ but some other ways.

Sometimes the Makefile is itself generated (e.g. by cmake or autoconf) and its generator requires some specific file tree organization.

A common reason to put all sources in src/ is cross-compilation, or compilation for different styles of targets (perhaps a debug release, and an optimized one). Then you would put all source code in src/ and ensure that make (and gcc) don't put object files in that src/ directory, but in some other one (e.g. obj-x86 for X86 object files, obj-arm for ARM object files, etc...), perhaps specific not only to the ISA but also to the ABI. So you could end up putting object files and executables in a long named directory such asobj-x86_64-linux-optimized and obj-PowerPC-AIX-debug. BTW, the src/ directory could even be shared on several machines (e.g. NFS mounted) and read-only (e.g. shareable by several users).

Notice that GCC requires to be built outside of its source tree.

Then, source code has somehow a different meaning for make (actually, for compilers like GCC) and for developers.

The social definition (used by developers) of source code is: the preferred form of a program on which human developers work (You'll find that definition expressed clearly by free software movements).

For a compiler like GCC or Clang, the source code is simply the translation unit given as input to the compiler (that is .c and .h files processed as input by the gcc compiler). In many (but not all) cases, such C files are genuine source code, because the human developers write them.

In some cases, C or C++ "source" files (as known by gcc or g++ or clang or clang++) are generated (in that case, for developers they are no more source code, but for gcc they are still an input source). A classical example is of course C files generated by bison. See this mine answer for a general discussion of that idea.

An other example (where C files are in some common directory) is given by domain-specific (or high-level) languages implementations compiled to C (e.g. Bigloo, Chicken Scheme, my old GCC MELT, or even the old C with classes -precursor of C++- in the 1980s).

When such implementations are more or less (or even entirely) bootstrapped, you really want to keep the generated C files together, perhaps in some src/ directory (or some generated/ one). And you could even put these under your version control system (e.g. git), notably for languages having a single implementation (otherwise, you won't be able to build such a compiler; you need the generated C code to build it and later recompile it with itself), and you'll certainly distribute such (generated) C files in a source tarball.

At last, very large projects of thousands of C or C++ -or Ocaml- files (even entirely human written) tend to group these in subdirectories, in particular because a single large directory of many thousands *.c files is not "readable" by (or friendly to) humans.

On the contrary, for a small project of at most a hundred thousands lines of code in several dozens of C source files with a manually written Makefile, you'll better put all *.c & .h files in the same directory containing that Makefile.

But having or not some src/ directory, or putting or not the object files produced by the compiler in the same directory containing the source files or the Makefile, is still largely a matter of taste, opinions, conventions, and habits. I recommend to study the existing practice in free software projects (similar to your project) on github or elsewhere.

这篇关于我在哪里放置项目的makefile?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！