Re:include file problems

Re:include file problems

[Nacho de los Ríos Tormo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]

I am also having this problem on a SuSE 7.0 installation. For example:

I'm trying to call	the library function:

	gettimeofday(struct timeval* tv, struct timezone * tz).

According to man pages, I need

#include <sys/time.h>   (which should expand to /usr/include/sys/time.h)
#include <unistd.h>      (which should expand to /usr/include/unistd.h)

SNav is unable to find the correct files -- which are indeed there.

I have toyed with the project settings include tab, as well as with the build 
settings. Depending on the combination, it either finds /usr/include/time.h 
(wrong file) or /usr/include/sys/unistd.h (also wrong). 

SNav only manages to find the correct files if I include them explicitly in 
the project (which calls for a trip to the project editor and to have the 
project reparsed). But these files themselves do include a variety of other 
files, which in their turn call others.

Trying to manually include all the tree soon leads into confusion and 
dispair. And this is just for gettimeofday()! The thought of throwing in some 
threads and an ncurses interface sends shivers down my spine.

Any ideas on what is wrong?

-- 

Nacho de los Ríos Tormo
Procedimientos Integrados S.L.
Sevillanos, 67
28609 Sevilla la Nueva, Madrid
SPAIN

Re:include file problems

[Mo DeJong]

On Tue, 28 Nov 2000, Nacho de los =?iso-8859-1?q?R=EDos=20Tormo?= wrote:

> I am also having this problem on a SuSE 7.0 installation. For example:
> 
> I'm trying to call	the library function:
> 
> 	gettimeofday(struct timeval* tv, struct timezone * tz).
> 
> According to man pages, I need
> 
> #include <sys/time.h>   (which should expand to /usr/include/sys/time.h)
> #include <unistd.h>      (which should expand to /usr/include/unistd.h)
> 
> SNav is unable to find the correct files -- which are indeed there.
> 
> I have toyed with the project settings include tab, as well as with the build 
> settings. Depending on the combination, it either finds /usr/include/time.h 
> (wrong file) or /usr/include/sys/unistd.h (also wrong). 
> 
> SNav only manages to find the correct files if I include them explicitly in 
> the project (which calls for a trip to the project editor and to have the 
> project reparsed). But these files themselves do include a variety of other 
> files, which in their turn call others.
> 
> Trying to manually include all the tree soon leads into confusion and 
> dispair. And this is just for gettimeofday()! The thought of throwing in some 
> threads and an ncurses interface sends shivers down my spine.
> 
> Any ideas on what is wrong?

Sounds like a bug. Why don't you take a shot at fixing it?
Take at look at the Preferences&::AddInclude methods at
line 879 of gui/preferences.tcl. That should get you started.

Mo DeJong
Red Hat Inc

Re:include file problems

[Nacho de los Ríos Tormo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]

> > SNav only manages to find the correct files if I include them explicitly
> > in the project (which calls for a trip to the project editor and to have
> > the project reparsed). But these files themselves do include a variety of
> > other files, which in their turn call others.
> >
> > Trying to manually include all the tree soon leads into confusion and
> > dispair. And this is just for gettimeofday()! The thought of throwing in
> > some threads and an ncurses interface sends shivers down my spine.
> >
> > Any ideas on what is wrong?
>
> Sounds like a bug. Why don't you take a shot at fixing it?
> Take at look at the Preferences&::AddInclude methods at
> line 879 of gui/preferences.tcl. That should get you started.
>
> Mo DeJong
> Red Hat Inc

I will try, but bearing in mind that I have no previous experience with 
either C++ or TCL/Tk don't expect results any time soon ... :-(

Still, doesn't it seem unlikely that it be a problem in the source code? If 
it were, I'm sure everybody that had tried to build a program of any 
significance with SNav would have found the same problem. Most programs 
written nowadays must include files that are in subdirs of usr/include.

Could it be something to do with environment variables or directory 
structure? After all, it seems that the problem occurs with SuSE but not with 
Red Hat ... Could you point me in some direction?

Thanks for your support,

Nacho de los Ríos Tormo

Re:include file problems

[Nacho de los Ríos Tormo]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --]

Sorry for pestering you, but I would be happy to help have this bug fixed (if 
indeed a bug). My C++ knowledge is limited and my TCL/Tk knowledge 
NONEXISTANT, so any help from your part would greatly speed me up.

> > > SNav only manages to find the correct files if I include them
> > > explicitly in the project (which calls for a trip to the project editor
> > > and to have the project reparsed). But these files themselves do
> > > include a variety of other files, which in their turn call others.
> > >
> > > Trying to manually include all the tree soon leads into confusion and
> > > dispair. And this is just for gettimeofday()! The thought of throwing
> > > in some threads and an ncurses interface sends shivers down my spine.

Dumb me! Why not add the whole /usr/include and all its subdirectories in one 
go with the project editor? .... Well, I've done so, so all involved files 
MUST now be included in the project. Still I get the same compilation errors:
	
	dos_in_lin.c: In function 'get_time_ms'
	dos_in_lin.c: 30: 'timeval' undeclared (first use in this function)
	....
	make: *** [dos_in_lin.o] Error 1
	+++ End +++

Thanks for your support,

Nacho de los Ríos Tormo
Procedimientos Integrados S.L.
Sevillanos, 67
28609 Sevilla la Nueva, Madrid
SPAIN

Re: include file problems

[Bruce Stephens]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

Nacho de los Ríos Tormo <irios@proin.es> writes:

[...]

> Dumb me! Why not add the whole /usr/include and all its
> subdirectories in one go with the project editor? .... Well, I've
> done so, so all involved files MUST now be included in the
> project. Still I get the same compilation errors:
> 	
> 	dos_in_lin.c: In function 'get_time_ms'
> 	dos_in_lin.c: 30: 'timeval' undeclared (first use in this function)
> 	....
> 	make: *** [dos_in_lin.o] Error 1
> 	+++ End +++

That's a compiler error: it's got nothing to do with Source Navigator.
SN doesn't tell the compiler what header files to use.  Something like
this ought to compile, regardless of what include files Source
Navigator finds:

#include <sys/time.h>
void
foo()
{
    struct timeval tv;
    struct timezone tz;
    gettimeofday(&tv, &tz);
}

-- 
Bruce Stephens			Bruce.Stephens@MessagingDirect.com
MessagingDirect(UK) Ltd		<URL: http://www.MessagingDirect.com/ >

Re:include file problems

[Ben Elliston]

   SNav only manages to find the correct files if I include them
   explicitly in the project (which calls for a trip to the project
   editor and to have the project reparsed). But these files themselves
   do include a variety of other files, which in their turn call others.

I could be wrong, but my recollection is that S-N will only include files in
your project that are explicitly listed at project creation time.  That is,
#include directives are not followed as you might expect.  This is in fact a
good idea, since it gives you more control over how big your database gets.

Often, users don't care about header files or, say, the function prototype
for strcmp(3).  If you use the project editor to include all of
/usr/include, does it work as expected?

Ben

include file problems

[Merlyn Cousins]

Ok..first i'd like to thank you for responding.
In answer to your questions...I'm a linux man 
I'm using SuSE 6.1 (with compiled version of snavigator)
I had no errors during the compilation.
everything else seems to work but the include stuff.
Which really gives me problems for obvious reasons.
as far as double clicking on include files..yes i do that
and the Prog responds with (file not found) but it's there.
It seems to do this anytime the syntax of #include <a directory/filename>
is used.

also a quick question for you...
Why do you have to click on the include files to bring them into the project?
this can be a real pain!!
shouldn't there be a option of some sort that Snav does a recursive search and auto
loads the #include files?
I mean if these files were in the directory or a subdirectory of the current project
and a new project was created, would not Snav auto bring them in?
having to double click through the tree is a real time waster.
So anyway thanxs again..
If i can get these points points worked out Snav along with gvim
will be a GREAT aid to me in helping to Understand (reverse engineer) source code.


Hi,

I'm assuming that you are double clicking on the include
file in the include browser.  (?)

What OS are you running on?

I've heard of this bug before but haven't managed to
reproduce it on my Red Hat 6.2 box.  (This is meant to
problems on Windows version also.)

Ian.

"Merlyn(root)" wrote:
> 
> Perhaps someone can help me with a problem I am having using snavigator.
> when I'm trying to work with include files that use the form
> #include <sys/stabs.h> for example (where a directory below the include
> directory is used ..i.e let's say /usr/include) snavigator says (file not
> found) now the file is there...and /usr/include is specified in the path for
> the include file search. so why doesn't it work?
> 
> if anyone can help I would great accpreciate it
> 
> thanks
> 
> merlyn

Re: include file problems

[Ian Roxborough]

Hi,

Merlyn Cousins wrote:
> everything else seems to work but the include stuff.
> Which really gives me problems for obvious reasons.
> as far as double clicking on include files..yes i do that
> and the Prog responds with (file not found) but it's there.
> It seems to do this anytime the syntax of #include <a directory/filename>
> is used.

Where are your system include files?  Source-Navigator
at the moment only knows to look into /usr/include, which
means that it could be miss a lot of things (?).
In the preferences dialog there is an "Includes" tab, this
lets you add more include directories for systems include etc.

(Of course this might be a bug in the parser given #inclucde ""
vs. #include <>)

> also a quick question for you...
> Why do you have to click on the include files to bring them
> into the project?
> this can be a real pain!! shouldn't there be a option of
> some sort that Snav does a recursive search and auto loads
> the #include files?
> I mean if these files were in the directory or a subdirectory
> of the current project and a new project was created, would
> not Snav auto bring them in?  having to double click through
> the tree is a real time waster.

One option could be adding /usr/include or whatever to the
project.  Maybe we need an "include system headers" option
when creating projects.

Ian.

> So anyway thanxs again..
> If i can get these points points worked out Snav along with gvim
> will be a GREAT aid to me in helping to Understand (reverse engineer) source code.
> 
> Hi,
> 
> I'm assuming that you are double clicking on the include
> file in the include browser.  (?)
> 
> What OS are you running on?
> 
> I've heard of this bug before but haven't managed to
> reproduce it on my Red Hat 6.2 box.  (This is meant to
> problems on Windows version also.)
> 
> Ian.
> 
> "Merlyn(root)" wrote:
> >
> > Perhaps someone can help me with a problem I am having using snavigator.
> > when I'm trying to work with include files that use the form
> > #include <sys/stabs.h> for example (where a directory below the include
> > directory is used ..i.e let's say /usr/include) snavigator says (file not
> > found) now the file is there...and /usr/include is specified in the path for
> > the include file search. so why doesn't it work?
> >
> > if anyone can help I would great accpreciate it
> >
> > thanks
> >
> > merlyn

Re: include file problems

[Merlyn]

Hi there....thanxs again for quick reply.

my include files are in /usr/include and directories below (/usr/include)
I tried changing the directory search path in INCLUDE preferences (no luck)
To give you an example of exactly what is going on.
consider this.
one of my include files is #include<sys/times.h>
this should resolve to /usr/include/sys/times.h
snav with or without directory /usr/include/sys specified in preferences does
not find the file...(and it's there).

as far as a option to bring in the headers into the current project without the
double clicking stuff... I  think that would be great!
Just have an option which resolves all (external yuk) (i.e. external from
current project) include files.

thanks alot
Merlyn!!

On Sat, 28 Oct 2000, you wrote:
> Hi,
> 
> Merlyn Cousins wrote:
> > everything else seems to work but the include stuff.
> > Which really gives me problems for obvious reasons.
> > as far as double clicking on include files..yes i do that
> > and the Prog responds with (file not found) but it's there.
> > It seems to do this anytime the syntax of #include <a directory/filename>
> > is used.
> 
> Where are your system include files?  Source-Navigator
> at the moment only knows to look into /usr/include, which
> means that it could be miss a lot of things (?).
> In the preferences dialog there is an "Includes" tab, this
> lets you add more include directories for systems include etc.
> 
> (Of course this might be a bug in the parser given #inclucde ""
> vs. #include <>)
> 
> > also a quick question for you...
> > Why do you have to click on the include files to bring them
> > into the project?
> > this can be a real pain!! shouldn't there be a option of
> > some sort that Snav does a recursive search and auto loads
> > the #include files?
> > I mean if these files were in the directory or a subdirectory
> > of the current project and a new project was created, would
> > not Snav auto bring them in?  having to double click through
> > the tree is a real time waster.
> 
> One option could be adding /usr/include or whatever to the
> project.  Maybe we need an "include system headers" option
> when creating projects.
> 
> Ian.
> 
> > So anyway thanxs again..
> > If i can get these points points worked out Snav along with gvim
> > will be a GREAT aid to me in helping to Understand (reverse engineer) source code.
> > 
> > Hi,
> > 
> > I'm assuming that you are double clicking on the include
> > file in the include browser.  (?)
> > 
> > What OS are you running on?
> > 
> > I've heard of this bug before but haven't managed to
> > reproduce it on my Red Hat 6.2 box.  (This is meant to
> > problems on Windows version also.)
> > 
> > Ian.
> > 
> > "Merlyn(root)" wrote:
> > >
> > > Perhaps someone can help me with a problem I am having using snavigator.
> > > when I'm trying to work with include files that use the form
> > > #include <sys/stabs.h> for example (where a directory below the include
> > > directory is used ..i.e let's say /usr/include) snavigator says (file not
> > > found) now the file is there...and /usr/include is specified in the path for
> > > the include file search. so why doesn't it work?
> > >
> > > if anyone can help I would great accpreciate it
> > >
> > > thanks
> > >
> > > merlyn

Re: include file problems

[Ben Elliston]

   Why do you have to click on the include files to bring them into the project?
   this can be a real pain!!
   shouldn't there be a option of some sort that Snav does a recursive search and auto
   loads the #include files?

Because often, parsing these files takes a lot of time and imports a lot of
detail into your project you don't care about.  It's unusual to really want
to know where strcmp() is declared, since you either know, or don't really
care.  Don't you agree?

Ben

Re: include file problems

[Eray Ozkural (exa)]

Ben Elliston wrote:
> 
> Because often, parsing these files takes a lot of time and imports a lot of
> detail into your project you don't care about.  It's unusual to really want
> to know where strcmp() is declared, since you either know, or don't really
> care.  Don't you agree?

A friend of mine used to make include directories into separate projects
for this purpose in VC++. Perhaps it's a useful function after all.
Though I don't know how it would be possible in sourcenav.

Thanks,
-- 
Eray (exa) Ozkural
Comp. Sci. Dept., Bilkent University, Ankara
e-mail: erayo@cs.bilkent.edu.tr
www: http://www.cs.bilkent.edu.tr/~erayo