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

Posted 2023-02-17

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

【英文标题】：Useful folder structure for Project-Euler (Make/Source)? [closed]

【发布时间】：2015-12-27 21:58:10

【问题描述】：

我目前正在尝试为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。

【问题讨论】：

我解决项目欧拉问题。每个问题都尝试使用名为 euler.c 的源文件和相同的 makefile。解决问题后，我将源文件重命名为 euler-42.c 并将其复制到存档文件夹。如果我正在处理与早期问题类似的问题，我会从该问题的源代码开始。很简单。

Project Euler 是一次令人谦卑的经历！完成一个问题后，请务必查看论坛上之前获奖者发布的解决方案，非常非常有趣。

@chqrlie 是的，我已经解决了很多问题，但只是随机的。现在我想创建一个很好的库，有很好的功能等等。

【参考方案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。

【讨论】：

太棒了，非常感谢！我可能会走这条路:)

抱歉，这是一个新帐户，我仍然无法投票。我只是注意到我可以接受答案:)

【参考方案2】：

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

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

【参考方案3】：

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

【讨论】：

我有一个基本相似的经验，但有些实用功能太有用了，不能扔掉，而且很难做好。共享代码并随意磨练它确实可以提高生产力。使用 git 对旧代码的分支以及向后移植新想法和错误修复有很大帮助。

你可能是对的！这给我带来了一个全新的方面。谢谢你的回答。