[Ns-bugs] [Bug 156] Rename string.h header to nsstring.h to ease gccxml parsing

[bugzilla-daemon@nsnam-www.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=156





------- Comment #2 from gjcarneiro at gmail.com  2008-03-31 17:24 -------
(In reply to comment #1)
> (In reply to comment #0)
> > In the gjc/ns-3-pybindgen-notracing branch I had to enable a workaround:
> > 
> >     http://code.nsnam.org/gjc/ns-3-pybindgen-notracing/rev/1431a85ce21b
> > 
> > to avoid the following GCC-XML bug:
> > 
> >     http://www.gccxml.org/Bug/view.php?id=6682
> > 
> > The bug is due to string.h being the same name as a standard include.  The
> > workaround involves forcing GCC-XML to parse this include before all others.  
> > 
> > It seems to work, though it's kind of ugly.  Maybe it's better to rename
> > string.h to nsstring.h, like we have nstime.h instead of time.h?
> 
> Well, I would much rather have nstime.h renamed to time.h since I don't think
> there are any technical reasons for this nstime.h name. I mean, next time, it
> will be socket.h or some other header: the race to make sure that we do not
> have similarly-named headers (as system headers) is sure to be lost one day or
> another.
> 
> Could it be that a "simpler" fix would be to simply use the ns3/foo.h notation
> for every public header ?

Yes, it's possible it will fix.  I myself am generating a 'everything.h' header
file for feeding into GCC-XML that includes all headers, and I already changed
it to use #include "ns3/foo.h" instead of #include "foo.h".  Unfortunately that
alone wasn't enough because some other ns3 header was being included first
which included "string.h" which got GCC-XML confused.  But maybe if _all_ ns3
headers use the ns3/ things may get fixed without forcing a certain order of
inclusion.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.