From: William S F. <ws...@fu...> - 2008-01-12 13:27:12
|
Olly Betts wrote: > On 2008-01-11, Jelmer Vernooij <je...@sa...> wrote: > > Just testing that an option does what it should do and perhaps in > > combination with one or two related options is usually sufficient. It's > > not possible to test with all possible input files either, so I don't > > see why it would be necessary to test with all possible option > > combinations. > > You obviously can't check all combinations of external inputs on most > programs, but the more options you have, the harder it is to provide > adequate test coverage. > > > Perhaps Samba could just ship with its own patched version of the SWIG > > library, but I'd rather not go there if it's avoidable. > > I'd generally recommend shipping generated sources (after bitter > experience of trying to ship just .i files). Otherwise users building > from source will need to have SWIG installed to build your software, and > you'll probably find that some SWIG versions are problematic with your > wrappers, so they'll need to have a suitable SWIG version installed, which > means they may not be able to just install a packaged version. So if > you ship sources generated with a known-good version of SWIG, you get > happier users and fewer SWIG-related bug reports. The download is > larger but the generated files are fairly repetitive, so do at least > compress well. > > And if you're shipping generated sources, then you need them to compile > with all the Python versions which your users will want to use. I'd be > suprised if that was only Python >= 2.5 at present. > My thoughts on all this are there is no perfect solution that will meet Jelmers requirements and provide backwards compatibility. Here are some suggestions: 1) Don't use gcc's -Wcast-qual. 2) Use a macro which adds the cast only if Python < 2.5 - Note that to make the code more readable, you just post process the generated code removing the macro. 3) Add in a -minpythonversion option which will remove the casts if Python >= 2.5. There are so many Python options, I'm not sure another will be so bad. I'd suggest that we then deprecate -modern and make this equivalent to -minpythonversion 2.2. However for this to work, you'd have to solve the technical problems I mentioned. Jelmer, which of these do you think is most practical? I'd prefer 2) as it will reduce the number of options, will seamlessly work with all versions of Python and the code can be made more readable by a simple sed post processing stage. William |