«

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

wrote:
> 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 wrote:
> wrote:
> > 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

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

In article < .com>,
<> wrote:
>
>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.
--
7842++

wrote:
> 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

<> wrote:
> 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:

<http://ctags.sourceforge.net/>

> 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

--
Philip Paeps Please don't email any replies
I follow the newsgroup.

Working capital doesn't.

wrote:
>
> 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.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson