On Sat, Aug 27, 2011 at 3:26 PM, Antoine Pitrou <solip...@pitrou.net> wrote:
> On Sat, 27 Aug 2011 15:14:15 -0700 > Dan Stromberg <drsali...@gmail.com> wrote: > > > On Sat, Aug 27, 2011 at 2:38 PM, Nadeem Vawda <nadeem.va...@gmail.com > >wrote: > > > > > On Sat, Aug 27, 2011 at 10:41 PM, Dan Stromberg <drsali...@gmail.com> > > > wrote: > > > > It seems like there should be some way of coming up with an xml file > > > > describing the types of the various bits of data and formal arguments > - > > > > perhaps using gccxml or something like it. > > > > > > The problem is that you would need to do this check at runtime, every > time > > > you load up the library - otherwise, what happens if the user upgrades > > > their installed copy of liblzma? And we can't expect users to have the > > > liblzma headers installed, so we'd have to try and figure out whether > the > > > library was ABI-compatible from the shared object alone; I doubt that > this > > > is even possible. > > > > > > > I was thinking about this as I was getting groceries a bit ago. > > > > Why -can't- we expect the user to have liblzma headers installed? > Couldn't > > it just be a dependency in the package management system? > > Package managers, under Linux, often split development files (headers, > etc.) from runtime binaries. > Well, uhhhhh, yeah. Not sure what your point is. 1) We could easily work with the dev / nondev distinction by taking a dependency on the -dev version of whatever we need, instead of the nondev version. 2) It's a rather arbitrary distinction that's being drawn between dev and nondev today. There's no particular reason why the line couldn't be drawn somewhere else. > Also, under Windows, most users don't have development stuff installed > at all. > Yes... But if the nature of "what development stuff is" were to change, they'd have different stuff. Also, we wouldn't have to parse the .h's every time a module is loaded - we could have a timestamp file (or database) indicating when we last parsed a given .h. Also, we could query the package management system for the version of lzma that's currently installed on module init. Also, we could include our own version of lzma. Granted, this was a mess when zlib needed to be patched, but even this one might be worth it for the improved library unification across Python implementations.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
