(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 ? I know that this will trigger much more fallout but it might be a good change from the point of view of the user, if only because they won't have to try to understand the difference between #include "foo.h" and #include "ns3/foo.h".

If we did that, renaming nstime.h to time.h would be the way to go I think.

(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.

(In reply to comment #2)
> (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.
>

I am not sure that my suggestion would be so much better from the POV of the user so, if you could try pre-processing all these headers to do the above-mentioned replacement just for gccxml, that might be really cool. I know that I am pushing more pain on you here. 

(In reply to comment #3)
[...] 
> I am not sure that my suggestion would be so much better from the POV of the
> user so, if you could try pre-processing all these headers to do the
> above-mentioned replacement just for gccxml, that might be really cool. I know
> that I am pushing more pain on you here. 
 
Preprocessing is a hack.  I was probing for an elegant solution.  I already have my own hack and it's working, so...

Just close the bug if you think it's not worth to fix.  Python bindings will be fine, I guess.

(In reply to comment #4)
> (In reply to comment #3)
> [...] 
> > I am not sure that my suggestion would be so much better from the POV of the
> > user so, if you could try pre-processing all these headers to do the
> > above-mentioned replacement just for gccxml, that might be really cool. I know
> > that I am pushing more pain on you here. 
> 
> Preprocessing is a hack.  I was probing for an elegant solution.  I already
> have my own hack and it's working, so...

If it is working for you, then, let's ignore the issue.

thanks !