title: Is it possible to use C++Builder and CMake to create Python modules?
body: <p>C++Builder's 32-bit compiler, bcc32, by default creates shared libraries using the cdecl calling convention, prefixing exported functions with an underscore, 
   e.g. '_functionName'. Visual studio, on the other hand, don't prefix exported functions.</p>
  
  <p>Python, when importing a pyd module, expects a function named PyInitialize_modulename. Since bcc32 prefix this function with an underscore, rendering it to be _PyInitialize_modulename, Python will not be able to import a bcc32 created module.</p>
  
  <p>Using CMake, does anyone know how to add a module definition file, .def, to alias the prefixed function, to an 'unprefixed' one, when compiling/creating the pyd module?</p>
  
  <p><em>Update.</em> In response to Mr. Lebeau's answer below (as a comment);
  This question is not about CTypes, but SWIG. CTypes allows for a simple way to wrap a C/C++ DLL, but mainly deals with C structures and POD data. </p>
  
  <p>Swig, on the other hand, allows a client to get object oriented objects in Python, analogous to the ones exported from a C++ DLL. Swig can do this as it process C++ headers. </p>
  
  <p>Swig does create a C++ file that is compiled into a .pyd file (in essence a DLL as noted). The first exported function that Python looks for when trying to load it as a module, is <strong>Pyinit_MyModule</strong> (Python 3). When using C++ Builder, this function is exported as <strong>_Pyinit_MyModule</strong>, as mentioned. Problem is that it is Swig that exports this function, and I can't as a client of Swig change the calling convention (afaik) for this function. </p>
  
  <p>I believe my initial belief that Python needed __stdcall for this functions is wrong, as VS by default is using cdecl, but without adding the '_', and it that works fine. </p>
  
  <p>However, setting the compiler flag to suppress underscores don't work either, as then some of the functions in the Python import libraries are rendered invisible, and become unresolved externals. So perhaps this problem is more complex than it may first look. But I guess it has nothing todo with calling conventions.</p>