Tag: 依赖项

类似Arduino的Makefile与依赖…？

我目前正在尝试使用SDCC OS编译器为STM8微控制器开发C库和项目模板。 我的目标是一个（几乎）与NOdu兼容的设置，类似于Arduino – 但是使用make + shellscripts而不是IDE（我的野心有限……） 目前我正在努力使用make来自动检测依赖项。 在Arduino中，用户只包含相关的头文件，例如“#include LCD-lib”，构建机制自动检测依赖关系并链接各自的库。 无需手动将其添加到IDE或Makefile。 我喜欢它的简单性，但到目前为止，我在创建相应的Makefile时失败了。 基本上这是Makefile应该实现的： 扫描项目根目录中的* .c文件以获取包含的标头。 请注意，这些文件位于不同的lib文件夹中 将所有包含的标头和（如果存在）相应的C文件添加到构建过程 为了最小化编译时间和大小，必须在构建期间跳过lib文件夹中未使用的C文件 我相信make可以做到以上所有 – 但不是我的制作经验…… 🙁 这是我想到的文件夹结构： ├── Library │ ├── Base │ │ ├── general STM8 sources and headers │ ├── STM8S_Discovery │ │ └── board specific sources and headers │ └── User │ └── optional user library […]

为什么这个makefile在’make clean’上执行目标

这是我目前的makefile。 CXX = g++ CXXFLAGS = -Wall -O3 LDFLAGS = TARGET = testcpp SRCS = main.cpp object.cpp foo.cpp OBJS = $(SRCS:.cpp=.o) DEPS = $(SRCS:.cpp=.d) .PHONY: clean all all: $(TARGET) $(TARGET): $(OBJS) $(CXX) $(CXXFLAGS) $(LDFLAGS) $(OBJS) -o $(TARGET) .cpp.o: $(CXX) $(CXXFLAGS) -c $< -o $@ %.d: %.cpp $(CXX) -M $(CXXFLAGS) $ $@ clean: rm -f $(OBJS) […]

类依赖工具

我正在寻找一个（最好是开源的）工具，给定大量的C / C ++代码，它将生成类（C ++）和/或文件（C）之间依赖关系的可视或XML图形。 我们的想法是，如果你必须将代码转换为另一种语言，你希望能够首先编译最低级别的类，并从那里开始构建。 所以，你首先需要确定那些类。 据我所知，Doxygen并不具备这种能力，但我可能错了。

自动为C / C ++可执行文件生成目标文件（链接器）依赖项

我目前正在开发一个灵活的C / C ++构建框架，我很快就会（希望）开源。 （有关背景，请参阅此问题）。 我使用以下命令为源/头文件生成#include文件依赖项。 gcc -M -MM -MF 有没有一种巧妙地推断可执行文件的链接器（.o文件）依赖关系（unit testing+在我的情况下为目标平台的主要可执行文件）使用gcc / GNU实用程序以类似的方式？ 目前，该框架做了很多假设，并且在确定这些依赖关系时非常愚蠢。 我听说过一种方法，其中nm命令可用于在目标文件中提供未定义符号的列表。 例如，在目标文件上运行nm（使用gcc -c编译）会出现类似这样的内容 – nm -o module.o module.o: U _undefinedSymbol1 module.o: U _undefinedSymbol2 module.o:0000386f T _definedSymbol 然后，人们将查找其他目标文件，其中定义了这些未定义的符号，以提供成功链接文件所需的目标文件依赖性列表。 这是确定可执行文件的链接器依赖性的最佳实践吗？ 有没有其他方法可以推断出这些依赖关系？ 在提出解决方案时，假设所有目标文件已经存在（即已经使用gcc -c编译）。

自动发现C依赖项

我需要为当前项目编写文档，列出所有.c文件，每个文件列出该文件直接或间接包含的每个.h文件。 这是一个大项目，虽然我们有理论上有这些信息的Makefile，但那些Makefile有时是不正确的（我们从另一家公司inheritance了这个项目）。 我们经常不得不做一个make clean ; make make clean ; make我们的更改实际上反映在重新编译中，所以我不想依赖这些Makefile。 那么是否有一个工具可以让我们给它一个.c文件和一个包含路径的名称，让它告诉我们.c文件直接或间接包含的所有.h文件？ 我们没有任何奇怪的东西 #define my_include “some_file.h” #include my_include 所以这个工具不需要是完美的。 在常规包含的包含路径中搜索.c和.h文件的任何内容都足够好。

制定配方以防止重建非依赖目标

我有以下项目目录结构： Prog /include /include/dir1 /include/dir2 /src /src/dir1 /src/dir2 App1依赖于mod1和mod2，其中App2仅依赖于mod1。 使用下面表示的makefile，模块和应用程序都可以正确构建 – 但是如果我对mod2进行了更改然后执行’make all’，即使App2没有依赖项，它也会被重建。 这是因为OBJ被传递到目标构建配方中的是所有OBJ，而不仅仅是当前目标所需的特定OBJ。 我想知道makefile的哪些更改只能将依赖对象传递给正在构建的当前目标。 makefile： CC := g++ LD := g++ TARGETS := app1 app2 MODULES := mod1 mod2 INC_DIR := $(addprefix include/,$(MODULES)) SRC_DIR := $(addprefix src/,$(MODULES)) BUILD_DIR := $(addprefix build/,$(MODULES)) SRC := $(foreach sdir,$(SRC_DIR),$(wildcard $(sdir)/*.cpp)) OBJ := $(patsubst src/%.cpp,build/%.o,$(SRC)) INCLUDES := -Iinclude $(addprefix […]