4

Is it normal to generate the list of source files (.c, .cpp etc, not headers) automatically?

How would you do it? I am thinking to use find and sed.

EDIT: The project is a library. All source files are inside the project directory. No unrelated source files are there. All object files are generated using the same compiler options. I am thinking to generate the list of all source files and then a dependency file for each source file following Tromey's way. It is a viable approach?

MORE EDIT: It is a fairly large C++ library. The project is being developed. Minimising recompilation is highly desired.

Thanks.

Jamie
  • 7,075
  • 12
  • 56
  • 86
pic11
  • 14,267
  • 21
  • 83
  • 119

2 Answers2

3

With GNU make you can use wildcards. See this question for an example.

Community
  • 1
  • 1
Nicholas Riley
  • 43,532
  • 6
  • 101
  • 124
3

Normal? It is common, but not wise.

Many people use Make wildcards or find or something similar to generate a list of all the source files that exist in a certain directory tree, then feed them to the compiler and link the objects together. This is a brittle solution that will get you into trouble. If a conflict appears among the source files (e.g. two separate definitions of void foo()) the linker will complain and it may not be obvious how to fix the problem. You may find yourself with a forest of source files, many of them unnecessary to your project, slowing down your builds and causing conflicts. And if you want to make use of some of these sources (but not all) in another executable, you'll have to resort to symbolic links or some other kludgery.

A better approach is to specify in the makefile which objects are necessary to a given target, then let Make figure out which sources to use. This is what Make is good at. There is no reliable way to maintain the object lists automatically, you just have to do it by hand, but it's not that much work; if you're changing them often enough that this is a real chore, then you're doing something wrong.

EDIT:
If the project is a library as you describe, then yes, this is a viable method, and a pretty good one. And Tromey's method will work quite nicely to prevent unnecessary recompilation.

Beta
  • 96,650
  • 16
  • 149
  • 150
  • I edited my question. It is a library. Only files belonging to the project are *unstable*, everything else won't change while the project is being developed. – pic11 Apr 17 '11 at 19:55
  • I would argue, at this point, that if you find yourself in need of having several "groups" of sources, then grouping them in separate folders is desirable too, so that maintainers can grasp what is used where! – Matthieu M. Apr 18 '11 at 06:28
  • @Matthieu M.: I agree, but I would add that each directory should contain a self-sufficient set of sources, one that can be compiled and tested without relying on other directories (or at most, it should require a few simple stubs for the outside sources). If the sources cannot be segregated that cleanly, I consider it a symptom of interface design problems. – Beta Apr 18 '11 at 14:01