Re: [Help-glpk] Patch for GLPK 4.35 to support SWIG

[Andrew Makhorin]

> Details of projects using swig can be found at:
>     http://www.swig.org/projects.html

Thank you for the reference.

> It is not necessary to use the same file in the #include statement
> as in the %include statement. Therefore it is not necessary to 
> modify glpk.h. I asked for these to be removed 18 months ago when 
> there were only 3. If Andrew takes them out for you, when he didn't 
> for me, I shall have to consider him sexist. It is better to use 
> your own file as there is a lot of other rubbish that can be 
> removed.

Sorry, probably I just missed this issue (no other reasons :).

(BTW, swig is claimed to be able wrapping *all* of ANSI C, thus, it
could be more tolerant to multiple definition of the same preprocessor
symbols, because this is valid in the standard C.)

Is it sufficient to enclose the #define's within #if 0/#endif, or they
should be removed at all?

> [...]

>> I guess that i'm suggesting that by including the glpk.i
>> interface file in the GLPK source tree, it might encourage others 
>> to use the SWIG-generated wrappers as a foundation for writing 
>> clean interfaces to GLPK in other languages. As it currently 
>> stands, someone that wants to do this has to jump through a few 
>> hoops (write the SWIG interface file glpk.i, make changes to 
>> glpk.h, etc).

As I understand swig just reads C/C++ header files and translates
corresponding specifications into another language to produce the
wrapper code. Which problems may appear if glpk.i is not included in
the distribution? Does glpk.i depend on the wrapper's language or on
glpk.h (or on somewhat else)?


Andrew Makhorin