|Makefile questions Stanya@aol.com (2001-07-03)|
|Re: Makefile questions firstname.lastname@example.org (Matthew J. Lockner) (2001-07-06)|
|Re: Makefile questions email@example.com (Wim Yedema) (2001-07-06)|
|Re: Makefile questions firstname.lastname@example.org (Marc Britten) (2001-07-06)|
|Re: Makefile questions email@example.com (walter) (2001-07-06)|
|Re: Makefile questions firstname.lastname@example.org (Lex Spoon) (2001-07-17)|
|From:||Lex Spoon <email@example.com>|
|Date:||17 Jul 2001 23:30:12 -0400|
|Organization:||Georgia Institute of Technology|
|Posted-Date:||17 Jul 2001 23:30:12 EDT|
> What I need to do is figure out which files in the project are used
> for which applications - each build can consist of several
> applications. I'll be writing a Perl script (if this is possible) that
> basically spits out info about the files used for each application in
> the whole build - some files might be shared by more than on
> application in a single build.
If "make -n target" isn't enough, then I'm scared by what your
makefiles must look like. But here goes. :) Take all of this for
worth as much as you paid for it.
You already have one makefile analyzer on your system: make(1) itself.
Thus, the most direct way would seem to be to get a copy of make and
modify it with an extra command flag to it. If your makefile is
standard enough, you can even use GNU make instead of the one that
comes with the system -- it might be easier to get the source code for
As others have mentioned, this analysis gets harder if you have
recursive makefiles -- make itself doesn't know the whole dependency
graph! Besides that, with recursive makefiles, it is common that
unneeded libraries will get compiled if you specify a specific target
-- that is, the makefiles themselves don't represent the dependency
structure verp precisely.
Overall, instead of trying to write a complicated analyzer, you might
want to use this as an excuse to clean things up. First, recursive
make itself is problematic and usually isn't too hard to remove:
Second, you may have complicated shell commands being fired within the
makefile. If you get rid of recursive invocations, then you may be
able to remove a lot of these and have each shell command build one
target from one group of source files. (excepting targets like
"Install" and "clean"...) If you can't get rid of them, then it's
going to be very tough to do your analysis -- you'll have to parse
those commands and then write rules to handle the particular kinds of
commands being used in your makefiles.
Finally, in the spirit that it's even better to remove a problem than
to solve it, here are a couple of ideas:
1. You could use another build tool than make. Almost all
replacements for make can represent dependency graphs
directly, and thus, I would think, would be easier to analyze.
I'm partial to Jam, but if you like Perl, CONS might work
better for you.
2. Even if you stick with make, you don't have to write
makefiles directly. Instead, why not generate the makefiles
from a script? Think of the makefile as an assembly language,
and encode all the real high-level structure in the script.
The main benefit is that scripting languages have high-level
language features (like subroutines :)) that can encode the
build structure in a human-readable form. A secondary benefit
is that the generated makefiles can be very simple (though
verbose!), and thus can be easier to understand both for
humans and programmers. In particular, it is good to get rid
of pattern-based rules.
With either of these replacements, the analysis will be easier, and
the humans will be happier, too. The main downside is that you have
to convince your coworkers to switch, even if you volunteer to do the
work. Hand-written recursive makefiles were good enough for all of
our grandpappy's, and I've found that people strongly resist changing.
Return to the
Search the comp.compilers archives again.