On Tue, 29 Jul 2003, Stas Bekman wrote:
Randy Kobes wrote: [...]
I'll take a look at this tonight as well - it'd probably be easier to change, for Win32, the assumption of the name of the httpd binary when apxs is present.
Thanks Randy!
Thanks for looking this over, Stas - I know you're really busy right now ... I've attached a diff incorporating the earlier suggestions - this one also has an additional fix to adjust the file names to be cleaned on Win32, which are different.
As far getting the right name for the Win32 binary goes with apxs present, I don't think there's an ideal solution ... To summarize, the problem is that apxs -q TARGET ( = httpd) is used in Apache-Test for the name of the apache binary, whereas in other places (in apxs itself, for example) it's used to represent "httpd".conf. What I ended up doing here is following the Apache-Test convention of setting $vars->{target} to Apache.exe for Win32 - this means overwriting the apxs value, which isn't great, but I guess as long as the same convention is followed throughout the package, it should be OK.
+1 on the patch
Randy, whatever you think is the best for win32, please go ahead with it. Untill we get someone else on win32 involved, you are pretty much free to decide how to handle things and what's the best for the user, as long as the changes don't break the code on other platforms. It's really hard to judge what's good or less good without seeing the problem. Perhaps somebody else can do that. I remember Philippe was trying to set win32 env, but he is now in transition from one continent to another...
On the other hand, I really dislike the fact that the code gets too many conditionals, making it much harder to comprehend. We should consider to use subclasses for win32 (or any other platform that requires too many special cases). What do you think? There is no hurry for now, but we should keep it at the backs of our heads (unless of course you think it's a cool idea and want to go with it right now ;). The good thing is once subclassed, there is very little danger that the code on other platforms will go broken.
__________________________________________________________________ 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
