On 2003.01.26 11:46 Nick Ing-Simmons wrote:
Is there any possibility of NO_EMBED going back in? It seems to me that it is one set of ifndef/endif pair around the whole file. And this would be perfect. Even if we made SWIG re-order the include statements, we would still have problems if the name conflicts with the public interface of a class. There is no way around it except to undef the macro. So if I write code like (doesn't even have to be in a header)...This is possibly a SWIG problem in that it could do a better job here.I had not realized that: /* NO_EMBED is no longer supported. i.e. EMBED is always active. */ made it into the mainline - this is a step backwards :-(
class ZipFile {
public:
void do_open(std::string name);
...
};
I would need to undef do_open or I would never be able to call the ZipFile's do_open. And this is a big problem for SWIG because almost every use of SWIG is to wrap some already existing library or already existing code where we can't really decide to chagne the name of the interface functions.
If NO_EMBED does not go back in, can we add something to embed.pl that generates both an embed.h and a noembed.h? Because <iostream> needs at least 5 or 6 undef's and people have been having conflicts with other include files.The only thing I can suggest at present is to create a "noembed.h" and ask SWIG to include that before <iostream>. It would contain #undef do_open
John
