Is there any reason not to commit the changes for the new c++defs module? Earlier, I wrote:
| How can one easily find all the places where the GNULIB_NAMESPACE tag | is needed? Is there some way we can get the compiler to help with | this job? | | The reason I liked the idea of having the gnulib headers automatically | add the "using gnulib::FOO" directive was that it would require no | change to my code. One of the great things about gnulib with C is | that it allows the system functions to be replaced when needed without | having to change existing code. Retrofitting a large project with | namespace tags will be tedious at best, and likely to result in hard | to find errors. | | Is there some reason to not add using directives in the gnulib | headers for each system function that is placed in the gnulib:: | namespace? | | Oh, now I remember that doing this requires placing the system headers | inside a namespace, and I guess that could cause some trouble. But | would you be interested in trying it? I could do the testing and help | with making the required changes. Although I still think that it would be nice if we could find a way to make gnulib work with C++ without having to add a namespace tag to symbols, I can live with having to add the tag. It is better than having to try to avoid macro definitions in all source files that might include gnulib headers. If you would like to see more testing for the c++defs module before you commit the changes, then I'd be happy to help with that, but I could use a few pointers as to how to handle local changes to gnulib in Octave's source files so that people who check out the Octave sources from our Mercurial archive and the gnulib sources from the gnulib git archive can use the patches you proposed. Thanks, jwe
