Related articles |
---|
Makefile questions Stanya@aol.com (2001-07-03) |
Re: Makefile questions lockner@chaos.cns.uni.edu (Matthew J. Lockner) (2001-07-06) |
Re: Makefile questions yedema@natlab.research.philips.com (Wim Yedema) (2001-07-06) |
Re: Makefile questions yugami@monochromatic.com (Marc Britten) (2001-07-06) |
Re: Makefile questions walter@digitalmars.com (walter) (2001-07-06) |
Re: Makefile questions lex@cc.gatech.edu (Lex Spoon) (2001-07-17) |
From: | Stanya@aol.com (Stan) |
Newsgroups: | comp.compilers,comp.unix.programmer |
Date: | 3 Jul 2001 23:18:05 -0400 |
Organization: | http://groups.google.com/ |
Keywords: | tools, question |
Posted-Date: | 03 Jul 2001 23:18:05 EDT |
I'm working on a project that has to do with the make command in UNIX
to build projects. There are makefiles involved - in fact, a makefile
tree where there subdirectories with their own makefiles which are
called upon by the main makefile (recursive makes). These deal with
C/C++ sources for the most part, but not limited to.
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.
Is there any possible way from reading the main makefile (root
directory of the project) and extracting this information? I'm on
HP-UX, but I use ClearCase which, in turn, provides clearmake - their
own version of the UNIX make(1). I figured out that by running
clearmake w/ the -w -d and -n options, I get a dry run that gives me
the names of all the directories and files used in the build for the
project, but I still haven't found a way to separate this by
application or executable, IF possible at all.
Thanx for any help I can get!!!
[Sounds like a hard problem. Makefiles can be pretty messy. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.