Richard Palmer wrote:
> Hello William,
>
> On Tue, Mar 10, 2009 at 6:23 AM, William S Fulton
> <wsf@...> wrote:
>> Richard Palmer wrote:
>>> Is it possible for a language module to process the parse tree
>>> nodes in the order given in the interface file, rather than
>>> the order of declaration in the header file ?. I can't seem to
>>> change this without an awful hack.
>>>
>> I'm not sure I follow. There is only one order and that is the order
>> declared in the interface file and this order will include any header files
>> %include'd. Are you perhaps confusing what is put in the %{ ... %} block,
>> which SWIG does not parse, with what is outside of these blocks?
>
> Sorry I should have written more.
>
> Say the header file contains 100s of functions but we are just
> interested in a few of them. We also want to ensure
> that even if these functions are re-ordered in a later header file,
> the order swig parses them will remain the same --
> that is, the order they are listed in the interface file.
>
> This is all for a SNMP MIB and agent generating language module I am
> playing around with (I'm not sure if it will be of
> much use, but it's an interesting problem). The MIB will generate OIDs
> based on the parse order, and I don't want them
> to change just because the order in the header file is altered.
>
Okay, I see. This is similar to what is going to have to be solved in
the COM module where the GUID ought not to change from one invocation of
SWIG to the next.
Saying that, if you declare the functions in the interface file, then
you don't have a problem, consider:
// file foo.h:
void method1();
void method2();
void method3();
and interface file:
// foo.i:
%{
#include "foo.h"
%}
void method1();
void method2();
void method3();
SWIG will only ever see the functions as declared in foo.i, so if the
methods are re-ordered in foo.h, it won't change the order that SWIG sees.
However, if you had your interface file as such:
// new foo.i:
%{
#include "foo.h"
%}
%include "foo.h"
then SWIG will see any parse order changes.
I'm not sure if you can apply the following to your OIDs, but in the COM
module, I'd solve the GUID (128 digit hex number IIRC) problem by
generating the GUID based on the namespace name, class name, method
name, parameter names and SWIG module name (so a bit like a C++ mangled
function declaration name). Probably create a hash out of these for
something like the final 100 digits and then the initial 28 digits could
be based on a hash of some version text string passed in via a
commandline option. That way if the methods are re-ordered the GUID will
remain the same, but can be easily upgraded to a new version when the
user wants to. If by any chance you implement this, please send the code
for us for use in the COM module.
William
|