假设项目目录包含子目录，例如src，bin，lib，doc等。我在哪里放置项目的makefile？< / p>
例如，
有些项目将makefile放在项目根目录的src/子目录中，
一些项目将其makefile放在项目的根目录中。
第二种方式对我来说更符合逻辑。如果最好将makefile放在根目录src/或其他目录中，出于什么原因，是否可以提供案例？
答案 0 :(得分：3)
问题的其余部分是基于意见的，但最后一部分是基于意见的：
如果最好将makefile放在根目录，src /或其他目录中，出于什么原因，可以提供一些案例吗？
首先，该目录可能不会被称为src/，而是其他一些方式。
有时Makefile本身就会生成（例如cmake或autoconf），其生成器需要一些特定的文件树组织。
将所有源放在src/中的一个常见原因是交叉编译或针对不同样式的目标进行编译（可能是调试版本和优化版本）。然后，您将所有源代码放在src/中，并确保make（和gcc）不将目标文件放在src/目录中，而是放在其他目录中（例如，obj-x86表示X86目标文件，obj-arm表示ARM对象文件，等等......，可能不仅特定于ISA，还特定于ABI。因此，您最终可能会将目标文件和可执行文件放在一个长命名目录中，例如obj-x86_64-linux-optimized和obj-PowerPC-AIX-debug。顺便说一句，src/目录甚至可以在多台计算机上共享（例如NFS已安装）和只读（例如，可由多个用户共享）。
然后，source code对于make（实际上，对于像GCC这样的编译器）和开发人员而言，某种不同的含义。
源代码的社交定义（由开发人员使用）是：人类开发人员工作的程序的首选表单（您会发现该定义明确表达通过自由软件运动）。
对于像GCC或Clang这样的编译器，源代码只是作为编译器输入的translation unit（.c和.h gcc编译器处理为输入的文件。在许多（但不是全部）情况下，这样的C文件是真正的源代码，因为人类开发人员编写它们。
在某些情况下，C <或C ++“源”文件（由gcc或g++或clang或clang++知道）已生成（在这种情况下，对于开发人员来说，他们不再是源代码，但对于gcc，他们仍然是输入源）。一个经典的例子当然是由bison生成的C文件。有关该想法的一般性讨论，请参阅this我的答案。
另一个示例（其中C文件位于某个公共目录中）由特定于域的（或高级）语言实现compiled to C（例如Bigloo，Chicken Scheme，我的在20世纪80年代，旧的GCC MELT，甚至旧的C与C ++的类 - 前导 - 。
当这些实现或多或少（或甚至完全）bootstrapped时，您真的希望将生成的C文件保存在一起，可能在某个src/目录（或某些generated/目录中）。你甚至可以将它们放在你的版本控制系统下（例如git），特别是对于具有单一实现的语言（否则，你将无法构建这样的编译器;你需要生成的C代码来构建它后来用自己重新编译它，你肯定会在源tarball中分发这些（生成的）C文件。
最后，数以千计的C或C ++或者Ocaml文件（甚至完全是人类编写的）的大型项目倾向于将这些文件组合在子目录中，特别是因为一个包含数千*.c个文件的大型目录是对人类不具有“可读性”（或对其友好）。
相反，对于一个包含手动编写Makefile的几十个C源文件中最多十万行代码的小项目，你最好把所有*.c＆amp;包含.h的同一目录中的Makefile个文件。
但是是否有一些src/目录，或者是否将编译器生成的目标文件放在包含源文件或Makefile的同一目录中，<强烈> 仍然主要是品味，观点，习俗和习惯的问题。我建议在free software或其他地方<{3}}项目（类似于您的项目）研究现有的做法。