[Zope-Coders] Binary files in Zope

[Matthew T. Kromer]

Ken Manheimer wrote:

>On Fri, 26 Oct 2001, Matthew T. Kromer wrote:
>
>>Let's come up with a re-rationalization of how and where binary files go
>>in Zope; I'm currently cursing at building windows binaries due to a
>>reorganization of splitters for plugin indexes.  Its getting to the
>>point where it is VERY annoying from a packaging point of view.
>>
>
>I may have missed something - am i supposed to know what the current
>arrangement is for the "binary files"?  I'm not even sure *what* binary
>files you're talking about.  I gather this has to do with the binary build
>process - is that process common knowledge, and i'm, well, just an
>uncommon kinda person?-)
>

>
Well, right now, binaries (.so or .pyd files) are scattered all over the 
place; I'd prefer to try to collect them so you could draw a box around 
a section of the tree and say "binaries live here."  For instance, with 
the way the splitters are working, they're buried deep inside the tree 
e.g. 
lib/python/Products/PluggableIndexes/TextIndex/Splitter/UnicodeSplitter/UnicodeSplitter.so 


ugh.

I'm somewhat in favor of re-collecting the binaries back over to 
lib/Components, and copying the .so or .pyd file to lib/python after 
building.

The binary build process on Windows uses utilties\ExtensionBuilder.py to 
identify which directories contain a Setup file which thus identifies a 
place building has to take place.   If a new binary appears but not in a 
location identified to ExtensionBuilder, it wont get built on Windows.  

Furthermore, since we require that all symbols loaded by modules be 
unique to the loader, if you located all shared object files in a 
directory you'd more easily expose when naming conflicts existed (ie a 
recent change to the splitters is making it so all splitters could be 
loaded simultaneously -- previously, they all used the same entry point 
names.)