Hi, I've been thinking lately in the amount of bugs generated by improper handling of library versioning. And I realised that several developers don't understand the implications of subtle API changes (like adding a member to a struct that is member of another struct which happens to be used as an argument of a function call). Then I got the idea of generating an API description file from the public header files of the library, but in that description file, all public symbols have the types completely resolved to the basic types, so that that kind of subtle type change becomes easily noticed when comparing the description file of two different versions. It's important to realise that binary-compatible changes would be allowed even if the type definitions go under a refactoring in the library. I had take a look at the TableGen tool, and it looks like that is my starting point. So I ask, what do you think about such tool? what advices could you give me on starting that tool? daniel P.S.: please include me in CC's... I'm not subscribed...
On Feb 29, 2008, at 6:10 AM, Daniel Ruoso wrote:> Then I got the idea of generating an API description file from the > public header files of the librarySounds neat. In the past I've done this with objdump for the public symbols in a library. In theory you don't care about types no findable by the api. A nice tool would allow one to stamp the interface as release time, and then put that into the source so that one can get build errors when follow on work don't exactly match it. At flag days, one can then bump the major number and delete the interface file and essentially start over.
Sex, 2008-02-29 às 13:48 -0800, Mike Stump escreveu:> On Feb 29, 2008, at 6:10 AM, Daniel Ruoso wrote: > > Then I got the idea of generating an API description file from the > > public header files of the library > Sounds neat. In the past I've done this with objdump for the public > symbols in a library. In theory you don't care about types no > findable by the api. A nice tool would allow one to stamp the > interface as release time, and then put that into the source so that > one can get build errors when follow on work don't exactly match it. > At flag days, one can then bump the major number and delete the > interface file and essentially start over.That's even more cool :)... Is there some code of what you've done with objdump? daniel