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.
If that does the trick go for it. And +1 to rename.
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;
Ah, sorry, I didn't suggest to drop support for win32 build in the core. Just suggesting to may be break the build process into blocks, which can then be combined by some sort of script that will be run by win32 users. e.g. always building libapreq+mp2 together, and re-using .o objects from the mp2 source instead of figuring out where that extra library lives... but then there may be other 3rd party modules that will have similar issues...
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.
Right. It's a stick of two edges. You mentioned one edge. The other edge is by adding branching complexity you also make it harder for new people to join, risking with too few people knowing their way around, ending up with a huge spaghetti of code which becomes less and less maintainable. That's why some time ago, I suggested an idea of subclasses where win32 will implement its own nuances in its own subs, leaving the core alone. Granted that creates an enormous initial overhead for you Randy to do that split, but on the other hand it may attract more people to do the maintenance/development when there will be significantly less branching. Though I release that I'm sliding off the real topic, which is not the code branching but install issue on win32, which while just as annoying, is a different issue :)
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
