Re: Makefile questions

> 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
GNU make.




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:


    http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html




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.


                http://dmoz.org/Computers/Software/Configuration_Management/Make/


                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.




Sincerely,


Lex Spoon

Return to the comp.compilers page.
Search the comp.compilers archives again.