Project-Euler (Make/Source) 的有用文件夹结构？ [关闭]

Question

我目前正在尝试为Project-Euler 提供可靠的文件夹结构。

我目前的想法是这样的结构：

.
└── project-euler/
    ├── resources
    │   ├── primes.h
    │   ├── primes.c
    │   ├── factors.h
    │   ├── factors.c
    │   └── ...
    ├── 001_name_of_procect_one.c
    ├── 001_name_of_project_one.o
    ├── 002_name_of_project_two.c
    ├── 002_name_of_project_two.o
    └── ...

我对这种结构的问题是我将所有项目都放在一个文件夹中，我不知道如何为这种结构写Makefiles。

我可以为每个项目创建一个单独的目录，但是我必须写像#include "../resources/primes.h" 这样的东西，而且我不喜欢这种方法。

在这种情况下使用的典型项目结构是什么？我怎样才能为所有小项目写一个Makefile，同时仍将它们保留在同一个目录中？

编辑：顺便说一下，我使用clang。

Answer 1

如果您将实用程序文件保存在 resources 子目录中，您可以在主目录中创建单独的解决方案文件，其中包括顶部的必要头文件，例如：

#include "resources/primes.h"

并在底部包含实际代码

#include "resources/primes.c"

这样，您甚至不需要Makefile，因为默认规则将允许您直接从相应的源文件中创建每个目标：

make 002_name_of_project_two

make 甚至不会生成目标文件，只会生成可执行文件。

我个人更喜欢项目文件的名称更短，例如p42.c

Makefile 仍可用于点击make 或 IDE 的构建按钮。一个班轮就足够了：

all: p42

但是您可能想要添加一些依赖项，以便在您仅更改实用程序源时重新编译您的目标。添加这些行：（在第二行开头有一个 TAB）

%: %.c $(wildcard resources/*)
    clang $(CFLAGS) $(LFLAGS) -o $@ $<

您仍然应该为您的CFLAGS 环境变量添加适当的选项，以利用编译器捕获愚蠢错误的能力：-Wall -Wextra -Werror 用于gcc，-Weverything 用于clang。

Answer 2

如果您使用g++，则声明包含目录：

g++ -I../resources #rest of command line

Answer 3

这个关于图书馆的扩展评论将是一个与通常想法相反的庸俗回答。早些年，我花了无数时间维护我可爱的图书馆，但这个好主意涉及到一些问题。这样的库总是在进行中，但是当一个项目签收交付时，你不敢更改库，因为害怕破坏以前的项目，所以它必须被冻结。然后，您将拥有多个版本的库。现在，假设旧项目需要 mods，这需要更改库函数？您仍然无法使用当前版本，因为您必须重新进行之前的产品测试和保证。另一个反对意见是，我的一些所谓的优秀库函数在下一个项目中从来都不是我想要的。整个事情变成了维护的噩梦，我放弃了它。我现在发现，在 Project Euler 问题中，我可能需要一个阶乘函数。在一种情况下，一个简单的unsigned 函数会很好。在另一种情况下，我需要uint64_t 在范围内。在另一种情况下，这将是 unsigned 或 uint64_t 以某个常数为模。变化是无穷无尽的，当函数可能需要调用数百万次时，通用的单一功能方法是不合适的。所以我只是使用复制/粘贴解决方案从其他问题中挑选我需要的部分。