Re: xml2py different output (order of definitions) when running with same input file twice.

You're right about that the contents is functionally the same, but is
just generated in a "different order".

The xml2py is part of a bigger software project and it is inconvenient
not to be able to reproduce a build. Consider if you have a release
that you would like to re-build after the release to do bug fixes etc
for later dot release. Then you will have a diff on the auto-generated
files even when you have no changes to the code. It just doesn't feel
right even when the "content is the same".

I'll look into the ctypesgen.py and maybe switch to using that instead.

Thanks for the help


On Wed, Feb 9, 2011 at 11:00 PM, Chris Clark <[email protected]> wrote:
> Swix Blue wrote:
>>
>> I've been using ctypeslib in a project to share a common api between C
>> code and python code using C header files. It works great except that
>> I recently discovered that the xml2py function generates different
>> python code for the same input run twice. It looks like it has to do
>> with the enums in the header file. (The h2xml always generates the
>> same xml file).
>>
>> I've attached the header file simple.h, and two example outputs from
>> running:
>> .....
>> I'm using version 0.5.6 of ctypeslib.
>>
>> Is there a setting I could use to have xml2py always generate the same
>> python file for same header file?
>>
>
> I doubt there is a param for this. The contents appears functionally the
> same so the diffs shouldn't be a big deal, if it were me I wouldn't worry
> about it, just use the output and make sure you have a good test suite.
>
> ctypesgen does preserve order for each run if that really is a concern. E.g.
> below generates the same content for each run:
>
>   ctypesgen.py simple.h -osimple_ctypes.py
>
> If you need this in xml2py you'll probably need to add this yourself (see
> past mails in the archive on the current status of xml2py).
>
> Chris
>
>

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb