为更大的目录结构创建文件
我有几个目录,其中子目录包含 c 或 asm 文件,我希望它们全部编译/汇编,然后链接。我并不特别挑剔目标文件的去向(例如特殊的 bin 文件夹或 src 文件夹),只要 make clean 将它们全部删除即可。
结构看起来像这样:
/src
/dir1
/dir1_1
+file1_1.s
+file1_2.s
+file1.s
/dir2
+file2.c
我确信有一些简单的方法来创建一个编译所有文件的 makefile,而无需我指定它应该在哪里(可以使用通配符编译一个目录中的所有文件,但是然后呢?) 。
I've got several directories with subdirectories containing c or asm files and I want them all compiled/assembled and then linked. I'm not especially picky where the object files go (e.g. a special bin folder or in the src folder) as long as a make clean removes them all.
The structure would look something like this:
/src
/dir1
/dir1_1
+file1_1.s
+file1_2.s
+file1.s
/dir2
+file2.c
I'm sure there's some easy way to create a makefile that compiles all files without me having to specify where it should look (compiling all files in one directory is doable with wildcards, but what then?).
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
在 Google 上搜索“递归使被认为有害”。您会发现原始文章假设递归 make 过程是一种糟糕的做生意方式,并且您会发现一些指向其他地方的链接,这些链接争论了该命题的有效性。
基本上,有两种方法可以在目录层次结构中进行构建(使用
make
)。我经常开发一种产品,其中主构建序列由混合系统驱动,该系统使用 shell 脚本,每个目录都有一个 makefile。产品的一部分由“RMCH”makefile 管理;大部分都不是。构建脚本处理构建的各个阶段,并对目录进行排序,并在需要时在每个目录中运行
make
。 (源代码位于分布在多个目录中的 20k+ 个文件中 - 这是一个大项目/产品。)我还转换了一个中小型项目(大约 20 个相关目录和大约 400 个源文件)来使用RMCH(来自脚本+每个目录生成文件系统)。一开始有点令人兴奋,但现在已经完成了,效果非常好。我的做法是否正确还有待商榷;这主要是一个学习练习,尽管我也做了一些修改代码的工作,以使用现代的curses库,而不是用作代码一部分的古老的BSD库(过时的,如1982年的老式 - 代码是最后一次认真开发是在 1986 年左右),并且普遍升级到现代(标准 C)标准。这也是一个使用 git 的机会 - 所以,总而言之,这是一次相当广泛的学习经历。
如果你能全神贯注于 RMCH,那么它就是一个很好的系统。如果正确完成,通过完整且准确的依赖关系跟踪,它可以消除构建序列中的猜测工作,并且运行速度确实很快。然而,即使将一个中等规模的项目迁移到它也是相当困难的工作 - 在我工作的主要产品上执行此操作将是一项艰巨的任务,尽管系统很可能从中受益。
另一种方法是查看
make
的其他替代方案,例如cmake
、rake
、scons
、bras
、imake
或ant
或任何您喜欢的东西。其中大多数都可以通过 Google 搜索轻松找到;困难的是bras
,它基于 Tcl(如在 Tcl/Tk 中),但现在可能基本上已经死了。提到imake
更多的是为了完整性,而不是作为一个严肃的建议。您还可以查看 GNU Autotools。那些不放弃make
;他们构建在make
之上。Do a Google search for 'recursive make considered harmful'. You'll find the original article which postulates that the recursive make procedure is a bad way of doing business, and you'll find some links to other places which debate the validity of the proposition.
Basically, there are two ways to do builds in a directory hierarchy (with
make
).I work routinely on a product where the main build sequence is driven by a hybrid system that uses a shell script plus one makefile for each directory. One section of the product is managed by a 'RMCH' makefile; most of it is not. The build script deals with phases of the build, and sequences the directories, and runs
make
in each directory when it is time to do so. (The source code is in 20k+ files spread over a multitude of directories - it is a big project/product.)I've also converted a medium-small project (about 20 directories of relevance, and about 400 source files) to work with RMCH (from a script + makefile-per-directory system). It was a bit mind-blowing at first, but works pretty neatly now it is done. Whether I did it correctly is open for debate; it was primarily a learning exercise, though I also did some work modifying the code to work with a modern curses library instead of the archaic BSD library that was used as a part of the code (archaic, as in 1982-vintage - the code was last seriously developed in about 1986) and generally upgrading to modern (standard C) standards. It was also a chance to work with
git
- so, all in all, quite an extensive learning experience.If you can wrap your brain around RMCH, it is a good system. If done correctly, with complete and accurate dependency tracking, it removes the guess-work from the build sequence, and it does run fast. However, migrating even a medium size project to it is fairly hard work - it would be a daunting task to do it on the main product I work on, though the system might well benefit from it.
An alternative is to look at other alternatives to
make
, such ascmake
,rake
,scons
,bras
,imake
, orant
or whatever else takes your fancy. Most of those are easily discoverable via a Google search; the hard one isbras
, which is based on Tcl (as in Tcl/Tk), but is probably largely dead now. Andimake
is mentioned more for completeness than as a serious suggestion. You might also look at the GNU Autotools. Those do not abandonmake
; they build atopmake
.如果您的项目足够小,您可能会使用单个手工制作的 makefile,而不是更复杂的构建系统:查看 转换函数手册页 看看有什么可能。
您的示例项目可以使用以下非递归 makefile 进行编译:
但是,由于
make
可以访问 shell,因此您还可以使用标准的 UNIX 工具,例如find
,而不是使用一些类似的工具。有限的内置函数,例如If your project is small enough, you might get away with using a single hand-crafted makefile instead of a more sophisticated build system: check out the manual page on transformation functions to see what's possible.
Your example project could be compiled with the following non-recursive makefile:
However, because
make
can access the shell, you could also use standard unix tools likefind
instead of the somewhat limited builtin functions, eg