C Newbie - large src tree - where is something #defined?

[edhead2003]

Hello all,

I suppose the title says most of it... this has happened to me a couple
of times with large C projects. You inherit a large source tree with a
complex set of Makefiles. In this environment, what is the easiest way
to find out where, say, a certain struct is defined? This isn't a
problem if the label is distinctive but in my current problem, I am
trying to find out where a BOOL convenience type has been defined -
when I grep the tree, there are defs for it all over the place - which
one is my current compilation using?

Does this question make any kind of sense? Coming from java with its
explicit package-directory mapping this sort of thing just seems
incredibly hard to keep non-confusing in C.

Cheers,
cam

 

[David Resnick]

Hello all,

I suppose the title says most of it... this has happened to me a couple
of times with large C projects. You inherit a large source tree with a
complex set of Makefiles. In this environment, what is the easiest way
to find out where, say, a certain struct is defined? This isn't a
problem if the label is distinctive but in my current problem, I am
trying to find out where a BOOL convenience type has been defined -
when I grep the tree, there are defs for it all over the place - which
one is my current compilation using?

Does this question make any kind of sense? Coming from java with its
explicit package-directory mapping this sort of thing just seems
incredibly hard to keep non-confusing in C.

Cheers,
cam

A good way is, if your implementation supports it, to request that an
intermediate file be generated during compilation after the
preprocessing
step. For example, the -E flag of gcc. Exactly how to do this or
whether you can on your system is not on topic here, so you should
ask in a newsgroup appropriate for your compiler/OS.

-David

 

[David Resnick]

A good way is, if your implementation supports it, to request that an
intermediate file be generated during compilation after the
preprocessing
step. For example, the -E flag of gcc. Exactly how to do this or
whether you can on your system is not on topic here, so you should
ask in a newsgroup appropriate for your compiler/OS.

-David

A few other options if you can't take my other idea (make a
preprocessed file)

1) put in a test if it is defined after each include:
#include "foo.h"
#if defined(BOOL)
#error BOOL is defined in foo.h
#endif

Of course, you then need to go into foo.h and look at is includes and
so forth, can be irritating, but it should work eventually.

2) #define the thing after all the includes. Your implementation MAY
give you a very helpful hint about where the original definition
resides. Or it may not. Example of what a helpful compiler might tell
you:

temp(889)$ cat foo.c
#include "stdio.h"
#define NULL 1
int main(void)
{
puts("hello, world");
return 0;
}
temp(889)$ gcc -Wall -ansi -pedantic -o foo foo.c
foo.c:2:1: warning: "NULL" redefined
In file included from /usr/include/_G_config.h:14,
from /usr/include/libio.h:32,
from /usr/include/stdio.h:72,
from foo.c:1:
/usr/lib/gcc-lib/i386-redhat-linux/3.2.3/include/stddef.h:402:1:
warning: this is the location of the previous definition

-David

 

[Anonymous 7843]

I suppose the title says most of it... this has happened to me a couple
of times with large C projects. You inherit a large source tree with a
complex set of Makefiles. In this environment, what is the easiest way
to find out where, say, a certain struct is defined? This isn't a
problem if the label is distinctive but in my current problem, I am
trying to find out where a BOOL convenience type has been defined -
when I grep the tree, there are defs for it all over the place - which
one is my current compilation using?

Try adding "#define BOOL double" to the end of the source file in
question and recompile; there is a possibility your compiler will print
the file name and line number of the original #define, identifying
it as a redefinition or conflict. My favorite compiler does this,
yours may or may not.

The more permanent solution is to delete all of the #defines for BOOL
and replace them with a single typedef (or a single #define
if you insist) in one header file that all the other files use.

 

[jacob navia]

Hello all,

I suppose the title says most of it... this has happened to me a couple
of times with large C projects. You inherit a large source tree with a
complex set of Makefiles. In this environment, what is the easiest way
to find out where, say, a certain struct is defined? This isn't a
problem if the label is distinctive but in my current problem, I am
trying to find out where a BOOL convenience type has been defined -
when I grep the tree, there are defs for it all over the place - which
one is my current compilation using?

Does this question make any kind of sense? Coming from java with its
explicit package-directory mapping this sort of thing just seems
incredibly hard to keep non-confusing in C.

Cheers,
cam

If the code is C code, and you are in the windows OS, you can use the
lcc-win32 IDE.

1) Load all files in the ide. At the command prompt type:
wedit *.c
2) When you want to know where is a symbol defined right click in the
symbol and choose "Goto definition" in the popup menu.

lcc-win32 is available at:
http://www.cs.virginia.edu/~lcc-win32

 

[Philip Paeps]

I suppose the title says most of it... this has happened to me a couple of
times with large C projects. You inherit a large source tree with a complex
set of Makefiles. In this environment, what is the easiest way to find out
where, say, a certain struct is defined?

I like to use 'exuberant ctags' to keep track of my code. I use a Makefile
target to keep my tagfiles updated and my editor has a number of hooks that
allow me to jump from tag to tag and to search for tags.

You can get this little jewel here:

This isn't a problem if the label is distinctive but in my current problem,
I am trying to find out where a BOOL convenience type has been defined -
when I grep the tree, there are defs for it all over the place - which one
is my current compilation using?

As has been suggested, the easiest way to find that out, is to redefine it
close to where you have a problem with it. Many compilers/preprocessors will
complain that it's already been defined, and where it's been defined.

Does this question make any kind of sense? Coming from java with its
explicit package-directory mapping this sort of thing just seems
incredibly hard to keep non-confusing in C.

All it takes is some discipline.

- Philip

 

[CBFalconer]

I suppose the title says most of it... this has happened to me a
couple of times with large C projects. You inherit a large source
tree with a complex set of Makefiles. In this environment, what
is the easiest way to find out where, say, a certain struct is
defined? This isn't a problem if the label is distinctive but in
my current problem, I am trying to find out where a BOOL
convenience type has been defined - when I grep the tree, there
are defs for it all over the place - which one is my current
compilation using?

Does this question make any kind of sense? Coming from java with
its explicit package-directory mapping this sort of thing just
seems incredibly hard to keep non-confusing in C.

Hunt down cscope. Available everywhere. For winders use it under
DJGPP.