Stas Bekman <[EMAIL PROTECTED]> writes:
[...] > > Implementing functions in header files? Is that an acceptable > approach? At the moment there are just a few of them, but with time > the number may grow. For the typemaps, I'd say yes. In C++ it is accepted practice to define short *inline* functions in header files. In C the practice is somewhat suspect, because the "inline" semantics aren't always reliable (lots of pre-C99 compilers, including gcc [1]). In this circumstance the function symbols could wind up as globals, so folks building shared libraries might wind up with symbol collisions. However, the vast majority of the XS code is for module creation, where symbol collisions between modules are a common, managable problem for the OS. In fact, AIUI we're already relying on that by providing a few common symbols in both mod_perl.so and APR.so. > I have a different take on this whole never-ending win32 mess -- since > 99.99% of win32 users use precompiled packages, may be it's a total > waste of time and messing up of the code to make things easy to build > on win32? If there is only one or few people who make binary distros, > may be they could write a few scripts that will build mp2 and libapreq > by hardcoding paths, using .o files directly and what not, keeping the > core simple? I agree that the keeping the core simple is goodness, and I also note that the apreq2 typemaps are much worse in this regard. I'm just trying to find a common approach to this problem that'll work for both projects. footnotes: [1] - see http://www.gnu.org/software/gcc/c99status.html -- Joe Schaefer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
