質問: $(OBJECTS:.o=.d) $(TARGET): $(OBJECTS) $(COMPILER) -o $@ $^ $(LDFLAGS) $(OBJDIR)/%.o: $(SRCDIR)/%.cpp -mkdir -p $(OBJDIR) $(COMPILER) $(CFLAGS) $(INCLUDE) -o $@ -c $< all: clean $(TARGET) clean: -rm -f $(OBJECTS) $(DEPENDS) $(TARGET) -include $(DEPENDS) ``` 補足情報(FW/ツールのバージョンなど) -------------------- os: LinuxMint18.2(Cinamon) コンパイラ: g++ 5.4.0 make: GNU Make 4.1
回答: こんにちは。 疑問点は、作業の進め方なのでしょうか? どんなプロジェクトでも、「必要なソースを作り、ビルド・システムを構築し、ビルドしてデバッグする」、「必要に応じてソースを追加する」という作業手順は異なることはないと思います。diodeさんの手順も同様ですね。 > > しかしgithubなどで様々なプロジェクトを眺めてみるとこの作業方法をとってる > > プロジェクトを見た事がありません。 > > > そんなことはありません。多数のコミットがあるプロジェクトで一度もソースを追加したことがないプロジェクトは存在しないのでは? ビルド・ツリーとソース・ツリーが入り混じっているのは、結構デメリットが多いです。 「CMake : out-of-sourceビルドで幸せになる」という記事がありました。CMakeはこの2つを分ける、分けないどちらも対応していますが、分けた方が幸せという記事ですね。この記事で書かれている分けることのメリット/デメリットはCMake限定ではなく一般的な話です。 他に気になった点としては、includeとsrcフォルダが別れていることですね。 ソース・ツリー上でこの2つを分けているプロジェクトの方が多いのですが、個人的には分けない方が生産性は上がりやすいと感じます。例えばmodule.hppとmodule.cppを両方同じように修正することは多々あります。その際、近くに配置した方が楽なように感じます。微細差ですが「チリも積もれば」です。