On Tue, 29 Jun 2004, Stas Bekman wrote: > Joe Schaefer wrote: > > Stas Bekman <[EMAIL PROTECTED]> writes: > > > >>Joe Schaefer wrote: > >> > >>>As part of the effort to allow APR:: stuff > >>>to work outside of mp2, the xs/typemap file > >>>also needs examination: T_HASHOBJ, T_UVOBJ > >>>both have modperl_ dependencies. > >> > >>I'm not quite following, what kind of deps you are talking about, > >>Joe. e.g. T_HASHOBJ uses modperl_hash_tie which now resides in APR.so > >>and doesn't require mod_perl. Can you give me an example of how this > >>problem can be seen? > > > > It'll only manifest in apreq2 on Win32, unless Randy figures out > > how to link Upload.dll against APR.dll. > > I guess this is the best solution.
Actually, modperl_hash_tie (and the other functions from src/modules/perl/*.c that are provided by APR.so on *nix) are supplied by the static aprext library on Win32. So I think the most straightforward solution on Win32 is to arrange to have aprext.lib installed by mp2 into the Apache2 lib/ directory, so that 3rd party modules have access to any of these functions. For this it might be a good idea to rename the library to, eg, modperl_aprext.lib, to indicate better where it came from. If that's acceptable, I'll make up a patch for that - it's just a few lines to change. [ ... ] > 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? > > But then again, there is AIX which seems to be very > similar to win32 when it comes to linking. I guess the similarity of AIX and Win32 in this respect is a consideration ... Of course, I'm not happy either with all the branching Win32 introduces (although it's a nice challenge to try to keep it to a minimum :). I wouldn't want to see support for Win32 disappear from the core, though, as - building things for Win32 would then become more dependent on a select few, who in the long term may change, and so the support base would shrink significantly; - it'd be much harder to track down problems on Win32 if one then has to factor in possible problems in Win32-specific build scripts; - it would make it that much harder to encourage Win32 developers to participate. - more often than not the Win32 branching is due to changes in the core code (eg, a .c/.h/.xs file), rather than a pure build problem, and it would be really difficult to maintain a complete Win32 mod_perl branch. - other projects build mod_perl for their distributions (eg, IndigoPerl at http://www.indigostar.com/ and DeveloperSide.net at http://www.devside.net/), and if mod_perl didn't compile easily from the sources, they'd probably drop it; Again, I'm not happy with the branching, and realize not too many people build mp/apreq on Win32 - the thing that mostly keeps me going, in addition to pure interest, is that there does seem to be a good-sized user base of the Win32 binary distributions - around 40 downloads per day on average of the Perl/Apache binary on the Apache site (and this is just one of several such all-in-one packages), and around the same number for the ppm packages. -- best regards, randy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
