Mailing List Archive

good work, thanks sterls! what do people think about this general
renaming of ApacheModuleFoo.dll to mod_foo.so in win32 land? good? bad?
i guess this is the 2.0 convention, so we might as well get used to it.

On Thu, 21 Dec 2000, Doug MacEachern wrote:

> good work, thanks sterls! what do people think about
> this general renaming of ApacheModuleFoo.dll to
> mod_foo.so in win32 land? good? bad? i guess this is
> the 2.0 convention, so we might as well get used to it.

it makes me wet.

if anyone needs some background there was a huge thread on new-httpd about
this over the past few days with

Subject: [Win32] 1.3.15; my mod_foo.dll question on the table

many people chimed in and there are some interesting points... the biggest
benefit is being able to use the exact same conf file on win32 && unix, but
also better for docs.

sterling

Doug MacEachern wrote:

> good work, thanks sterls! what do people think about this general
> renaming of ApacheModuleFoo.dll to mod_foo.so in win32 land? good? bad?
> i guess this is the 2.0 convention, so we might as well get used to it.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org

> 2) only the ApacheModulePerl.dll has been changed to mod_perl.so to
> limit the diff


I didn't take a look at 1.3.15, but shouldn't it be mod_perl.dll instead of
mod_perl.so on win32 ? Or do they really use the .so extension also on win32
?

Gerald

-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------

yeah, its .so
take a look at the thread on new-httpd

basically on win32 it really don't matter none what the extension is....
microsoft .ocx files and .cpl files are apparently just dlls with a different
suffix.

sterling

Gerald Richter wrote:

> > 2) only the ApacheModulePerl.dll has been changed to mod_perl.so to
> > limit the diff
>
> I didn't take a look at 1.3.15, but shouldn't it be mod_perl.dll instead of
> mod_perl.so on win32 ? Or do they really use the .so extension also on win32
> ?
>
> Gerald
>
> -------------------------------------------------------------
> Gerald Richter ecos electronic communication services gmbh
> Internetconnect * Webserver/-design/-datenbanken * Consulting
>
> Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
> E-Mail: richter@ecos.de Voice: +49 6133 925151
> WWW: http://www.ecos.de Fax: +49 6133 925152
> -------------------------------------------------------------

> yeah, its .so
> take a look at the thread on new-httpd
>
> basically on win32 it really don't matter none what the extension is....
> microsoft .ocx files and .cpl files are apparently just dlls with a
different
> suffix.
>

Yes, I know. I just wanted to be sure

Gerald

On Thu, 21 Dec 2000, John K Sterling wrote:

> as stated in my earlier post, apache-1.3.15-dev was just changed so all
> modules on win32 look exactly like unix (e.g. mod_status.so). i
> proposed we should stay in sync with the httpd group. here is a minimal
> patch that seems to work: note
> 1) no docs have been updated in this patch
> 2) only the ApacheModulePerl.dll has been changed to mod_perl.so to
> limit the diff
> 3) i included the earlier patch to Makefile.PL so it looks in
> APACHE_SRC/src/Release as well as APACHE_SRC/src/CoreR for
> ApacheCore.lib
> 4) it does not patch the test directory
>
> if any win32 folks have opinions, or randy if you want to do it your own
> way thats great. i just figured i'd get the ball rolling so to speak.
> if this patch is acceptable, i will update the docs/test as well. i
> thought it would be easies to review with minimal changes.
>
>
> sterling
>

Hi,
This patch looks good - I like the renaming to .so; makes
one feel one's on a real system ...:) I wonder about compatability
with pre-Apache_1.3.15, though; even though this (I think) is
just a change in convention, and, for example, doing things
this way for pre-Apache_1.3.15 should be OK, would people get
too confused if a mod_perl.so was installed if they were building
against apache_1.3.12, say? Should we have an Apache version
check in there to use mod_perl.so for 1.3.15 and ApacheModulePerl.dll
for pre-1.3.15? The "advantage" to Windows, though, is that
it forces you to upgrade often, so adopting the 1.3.15 convention
right away might not cause a problem ....

best regards,
randy

Randy Kobes wrote:

> would people get
> too confused if a mod_perl.so was installed if they were building
> against apache_1.3.12, say? Should we have an Apache version
> check in there to use mod_perl.so for 1.3.15 and ApacheModulePerl.dll
> for pre-1.3.15?

Great point - this would also allow us to look in the correct place for the
ApacheCore.lib file depending on the version. Makefile.PL could patch these
things up - and that would simplify everyone's problems except for.... dah dah
dah... the documentation. It would be pretty wierd to have 2 sections in the
docs 1 for pre-1.3.15 one for post 1.3.15 but i suppose it would work.


> The "advantage" to Windows, though, is that
> it forces you to upgrade often, so adopting the 1.3.15 convention
> right away might not cause a problem ....
>

true - and it won't actually break it to use mod_perl.so in pre-1.3.15 builds,
it'll just be different from the standard modules naming.

i could go either way, though i think i advocate switching immediately to
mod_perl.so for consistency - and before we know it - this convention will be
the norm (especially considering all win32 users will most likely flock to
apache 2.0 when it comes out and should move to 1.3.15 asap).

thoughts? should we put version support into Makefile.PL and have 2
installation sections in the docs (pre/post 1.3.15) or just move to the new
convention and recomend an apache upgrade to 1.3.15 (which has a bunch of new
support for win32 users anyway)?

sterling

sounds great -

i'm sure doug wouldn't think of releaseing without it. Let me know if you
need anything else ... obviously i'll test/proof the final patch.

sterling

On Fri, 22 Dec 2000, Randy Kobes wrote:

> On Fri, 22 Dec 2000, John K Sterling wrote:
>
> > sorry it took so long to respond i had some 'real work' issues :) anyhoo, i am
> > really torn on this one. I still think mod_perl should immediately just switch
> > to the new-style .so - mod_perl has always been the closest darling to apache so
> > it only makes sense that it follows the bleeding edge. If the mod_perl
> > instructions so mod_perl.so everywhere then no-one should be confused... they
> > might double take, but they'll get over it fast.
> >
> > So what'dya think randy - i'll go with your gut feel - and my patch will be
> > there when things are more comfortable.
> >
> > sterling
>
> I'm convinced ...:) That's a good point to be on the edge; it
> may confuse some, but that'll happen whenever it's done, and
> everyone will eventually run into it with apache, so we might
> as well do it now.
>
> What we could do is just reverse my earlier suggestions - build
> a mod_perl.so, but copy it as ApacheModulePerl.dll if pre-1.3.15,
> and print out appropriate messages. I'll take your earlier
> patch and add some of this, if you like ...
>
> best regards,
> randy
>

i'd support whatever you guys decide on for win32 land. sterls, if you
wanna let me know if i should apply your patch from yesterday or wait for
another, that'd be choice.

----- Original Message -----
From: "John K Sterling" <sterling@covalent.net>
To: "Randy Kobes" <randy@theoryx5.uwinnipeg.ca>
Cc: <dev@perl.apache.org>
Sent: Friday, December 22, 2000 11:07 AM
Subject: Re: [PATCH] win32 module names now like unix


>
>
> Randy Kobes wrote:
>
> > would people get
> > too confused if a mod_perl.so was installed if they were building
> > against apache_1.3.12, say? Should we have an Apache version
> > check in there to use mod_perl.so for 1.3.15 and ApacheModulePerl.dll
> > for pre-1.3.15?
>
> Great point - this would also allow us to look in the correct place for
the
> ApacheCore.lib file depending on the version. Makefile.PL could patch
these
> things up - and that would simplify everyone's problems except for.... dah
dah
> dah... the documentation. It would be pretty wierd to have 2 sections in
the
> docs 1 for pre-1.3.15 one for post 1.3.15 but i suppose it would work.
>

Hi,
It would be wierd to have this, but I guess that's life now ....

> > The "advantage" to Windows, though, is that
> > it forces you to upgrade often, so adopting the 1.3.15 convention
> > right away might not cause a problem ....
> >
>
> true - and it won't actually break it to use mod_perl.so in pre-1.3.15
builds,
> it'll just be different from the standard modules naming.
>
> i could go either way, though i think i advocate switching immediately to
> mod_perl.so for consistency - and before we know it - this convention will
be
> the norm (especially considering all win32 users will most likely flock to
> apache 2.0 when it comes out and should move to 1.3.15 asap).
>
> thoughts? should we put version support into Makefile.PL and have 2
> installation sections in the docs (pre/post 1.3.15) or just move to the
new
> convention and recomend an apache upgrade to 1.3.15 (which has a bunch of
new
> support for win32 users anyway)?
>
> sterling

I think too advocating the switch is a good idea - as you say, most
Win32 people will probably move to 1.3.15 anyway - apparently it
will now be labelled as "initial release quality", rather than
"beta release quality". But perhaps we should not force the issue,
if reasonable. What we could do is
- search for the Apache lib in the directory according to the Apache
version, as in your patch;
- let mod_perl build an ApacheModulePerl.dll for now, and
change this to build a mod_perl.so later on, when this new
convention is the norm. This way, people not building with
1.3.15 won't panic when they can't find ApacheModulePerl.dll, and
those that are using 1.3.15 are probably aware of the needed
name change;
- if the user elects to install automatically with the INSTALL_DLL
attribute, copy ApacheModulePerl.dll to the indicated directory
as mod_perl.so or as ApacheModulePerl.dll, according to the
Apache version;
- if the user elects to install manually, they're probably aware
of the new convention if they're using 1.3.15; we could print out
a message from Makefile.PL that ApacheModulePerl.dll must
be copied to $APACHE/modules/mod_perl.so if 1.3.15 is being used.
More generally, we could have Makefile.PL print a about
this impending changeover;
- update the docs accordingly;

Does this sound reasonable?

best regards,
randy

sorry it took so long to respond i had some 'real work' issues :) anyhoo, i am
really torn on this one. I still think mod_perl should immediately just switch
to the new-style .so - mod_perl has always been the closest darling to apache so
it only makes sense that it follows the bleeding edge. If the mod_perl
instructions so mod_perl.so everywhere then no-one should be confused... they
might double take, but they'll get over it fast.

So what'dya think randy - i'll go with your gut feel - and my patch will be
there when things are more comfortable.

sterling

Randy Kobes wrote:

> ----- Original Message -----
> From: "John K Sterling" <sterling@covalent.net>
> To: "Randy Kobes" <randy@theoryx5.uwinnipeg.ca>
> Cc: <dev@perl.apache.org>
> Sent: Friday, December 22, 2000 11:07 AM
> Subject: Re: [PATCH] win32 module names now like unix
>
> >
> >
> > Randy Kobes wrote:
> >
> > > would people get
> > > too confused if a mod_perl.so was installed if they were building
> > > against apache_1.3.12, say? Should we have an Apache version
> > > check in there to use mod_perl.so for 1.3.15 and ApacheModulePerl.dll
> > > for pre-1.3.15?
> >
> > Great point - this would also allow us to look in the correct place for
> the
> > ApacheCore.lib file depending on the version. Makefile.PL could patch
> these
> > things up - and that would simplify everyone's problems except for.... dah
> dah
> > dah... the documentation. It would be pretty wierd to have 2 sections in
> the
> > docs 1 for pre-1.3.15 one for post 1.3.15 but i suppose it would work.
> >
>
> Hi,
> It would be wierd to have this, but I guess that's life now ....
>
> > > The "advantage" to Windows, though, is that
> > > it forces you to upgrade often, so adopting the 1.3.15 convention
> > > right away might not cause a problem ....
> > >
> >
> > true - and it won't actually break it to use mod_perl.so in pre-1.3.15
> builds,
> > it'll just be different from the standard modules naming.
> >
> > i could go either way, though i think i advocate switching immediately to
> > mod_perl.so for consistency - and before we know it - this convention will
> be
> > the norm (especially considering all win32 users will most likely flock to
> > apache 2.0 when it comes out and should move to 1.3.15 asap).
> >
> > thoughts? should we put version support into Makefile.PL and have 2
> > installation sections in the docs (pre/post 1.3.15) or just move to the
> new
> > convention and recomend an apache upgrade to 1.3.15 (which has a bunch of
> new
> > support for win32 users anyway)?
> >
> > sterling
>
> I think too advocating the switch is a good idea - as you say, most
> Win32 people will probably move to 1.3.15 anyway - apparently it
> will now be labelled as "initial release quality", rather than
> "beta release quality". But perhaps we should not force the issue,
> if reasonable. What we could do is
> - search for the Apache lib in the directory according to the Apache
> version, as in your patch;
> - let mod_perl build an ApacheModulePerl.dll for now, and
> change this to build a mod_perl.so later on, when this new
> convention is the norm. This way, people not building with
> 1.3.15 won't panic when they can't find ApacheModulePerl.dll, and
> those that are using 1.3.15 are probably aware of the needed
> name change;
> - if the user elects to install automatically with the INSTALL_DLL
> attribute, copy ApacheModulePerl.dll to the indicated directory
> as mod_perl.so or as ApacheModulePerl.dll, according to the
> Apache version;
> - if the user elects to install manually, they're probably aware
> of the new convention if they're using 1.3.15; we could print out
> a message from Makefile.PL that ApacheModulePerl.dll must
> be copied to $APACHE/modules/mod_perl.so if 1.3.15 is being used.
> More generally, we could have Makefile.PL print a about
> this impending changeover;
> - update the docs accordingly;
>
> Does this sound reasonable?
>
> best regards,
> randy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org

On Fri, 22 Dec 2000, John K Sterling wrote:

> sorry it took so long to respond i had some 'real work' issues :) anyhoo, i am
> really torn on this one. I still think mod_perl should immediately just switch
> to the new-style .so - mod_perl has always been the closest darling to apache so
> it only makes sense that it follows the bleeding edge. If the mod_perl
> instructions so mod_perl.so everywhere then no-one should be confused... they
> might double take, but they'll get over it fast.
>
> So what'dya think randy - i'll go with your gut feel - and my patch will be
> there when things are more comfortable.
>
> sterling

I'm convinced ...:) That's a good point to be on the edge; it
may confuse some, but that'll happen whenever it's done, and
everyone will eventually run into it with apache, so we might
as well do it now.

What we could do is just reverse my earlier suggestions - build
a mod_perl.so, but copy it as ApacheModulePerl.dll if pre-1.3.15,
and print out appropriate messages. I'll take your earlier
patch and add some of this, if you like ...

best regards,
randy

sounds great randy - do what you gotta do - i'll check it out on the other end
testing/proofing

sterling

Randy Kobes wrote:

> On Fri, 22 Dec 2000, John K Sterling wrote:
>
> > sorry it took so long to respond i had some 'real work' issues :) anyhoo, i am
> > really torn on this one. I still think mod_perl should immediately just switch
> > to the new-style .so - mod_perl has always been the closest darling to apache so
> > it only makes sense that it follows the bleeding edge. If the mod_perl
> > instructions so mod_perl.so everywhere then no-one should be confused... they
> > might double take, but they'll get over it fast.
> >
> > So what'dya think randy - i'll go with your gut feel - and my patch will be
> > there when things are more comfortable.
> >
> > sterling
>
> I'm convinced ...:) That's a good point to be on the edge; it
> may confuse some, but that'll happen whenever it's done, and
> everyone will eventually run into it with apache, so we might
> as well do it now.
>
> What we could do is just reverse my earlier suggestions - build
> a mod_perl.so, but copy it as ApacheModulePerl.dll if pre-1.3.15,
> and print out appropriate messages. I'll take your earlier
> patch and add some of this, if you like ...
>
> best regards,
> randy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org

----- Original Message -----
From: "John K Sterling" <sterling@covalent.net>
To: "Randy Kobes" <randy@theoryx5.uwinnipeg.ca>
Cc: <dev@perl.apache.org>
Sent: Friday, December 22, 2000 7:29 PM
Subject: Re: [PATCH] win32 module names now like unix


> sounds great randy - do what you gotta do - i'll check it out on the other
end
> testing/proofing
>
> sterling
>

Hi,
From your earlier patches, it occurred to me that if we're
going to go to this mod_perl.so convention, how about renaming
all things that reference ApacheModulePerl, for consistency?
For example, the attached tar.gz file, which unpacks into
src/modules/win32/mod_perl.mak
src/modules/win32/mod_perl.def
src/modules/win32/mod_perl.dsp
could replace the current
src/modules/ApacheModulePerl/ApacheModulePerl.mak
src/modules/ApacheModulePerl/ApacheModulePerl.def
src/modules/ApacheModulePerl/ApacheModulePerl.dsp
In these I incorporated your earlier patches to the .dsp
and .mak files to build a mod_perl.so.

This would mean some other changes; these are
in the attached win32.diff file. To summarize,
- Makefile.PL: use the src/modules/win32/* structure, as
well as incorporating your patch to find the Apache lib
in the new location for 1.3.15. This also will, according
to the apache version, install mod_perl.so as mod_perl.so
or as ApacheModulePerl.dll, if INSTALL_DLL is passed
to Makefile.PL. Finally, a message is printed out at the
end mentioning the new convention.
- INSTALL.win32: mention the new convention, as well
as change references from ApacheModulePerl.dll to
mod_perl.so.
- MANIFEST: changes the dsp file name
- t/* files: makes some changes to load mod_perl.so,
rather than ApacheModulePerl.dll.

I tried this out on both apache_1.3.15 and apache_1.3.12,
and it worked, but if you have a chance to try it ....

best regards,
randy

i'm pretty busy for the next couple of days -- i'll be able to review it
wednesday. is that soon enough? eyballing it i like what i see. my patch
was the ultra-minimal to get mod_perl.so built... but i totally agree with you,
everything should be switched.

i'll get back to you in a couple of days.

sterling

Randy Kobes wrote:

> ----- Original Message -----
> From: "John K Sterling" <sterling@covalent.net>
> To: "Randy Kobes" <randy@theoryx5.uwinnipeg.ca>
> Cc: <dev@perl.apache.org>
> Sent: Friday, December 22, 2000 7:29 PM
> Subject: Re: [PATCH] win32 module names now like unix
>
> > sounds great randy - do what you gotta do - i'll check it out on the other
> end
> > testing/proofing
> >
> > sterling
> >
>
> Hi,
> From your earlier patches, it occurred to me that if we're
> going to go to this mod_perl.so convention, how about renaming
> all things that reference ApacheModulePerl, for consistency?
> For example, the attached tar.gz file, which unpacks into
> src/modules/win32/mod_perl.mak
> src/modules/win32/mod_perl.def
> src/modules/win32/mod_perl.dsp
> could replace the current
> src/modules/ApacheModulePerl/ApacheModulePerl.mak
> src/modules/ApacheModulePerl/ApacheModulePerl.def
> src/modules/ApacheModulePerl/ApacheModulePerl.dsp
> In these I incorporated your earlier patches to the .dsp
> and .mak files to build a mod_perl.so.
>
> This would mean some other changes; these are
> in the attached win32.diff file. To summarize,
> - Makefile.PL: use the src/modules/win32/* structure, as
> well as incorporating your patch to find the Apache lib
> in the new location for 1.3.15. This also will, according
> to the apache version, install mod_perl.so as mod_perl.so
> or as ApacheModulePerl.dll, if INSTALL_DLL is passed
> to Makefile.PL. Finally, a message is printed out at the
> end mentioning the new convention.
> - INSTALL.win32: mention the new convention, as well
> as change references from ApacheModulePerl.dll to
> mod_perl.so.
> - MANIFEST: changes the dsp file name
> - t/* files: makes some changes to load mod_perl.so,
> rather than ApacheModulePerl.dll.
>
> I tried this out on both apache_1.3.15 and apache_1.3.12,
> and it worked, but if you have a chance to try it ....
>
> best regards,
> randy
>
> ------------------------------------------------------------------------
> Name: win32.tar.gz
> win32.tar.gz Type: application/gzip (application/gzip)
> Encoding: base64
>
> Name: win32.diff
> win32.diff Type: unspecified type (application/octet-stream)
> Encoding: quoted-printable

Sorry about the delay --

finally got a second to breath and test out this patch randy.

It looks great - +1 on a commit before 1.25 doug.

one nitpick - INSTALL.win32:95 still references ApacheModulePerl.dll....
i like the message at the end of running perl Makefile.PL explaining the name
change.

sterling

Randy Kobes wrote:

> ----- Original Message -----
> From: "John K Sterling" <sterling@covalent.net>
> To: "Randy Kobes" <randy@theoryx5.uwinnipeg.ca>
> Cc: <dev@perl.apache.org>
> Sent: Friday, December 22, 2000 7:29 PM
> Subject: Re: [PATCH] win32 module names now like unix
>
> > sounds great randy - do what you gotta do - i'll check it out on the other
> end
> > testing/proofing
> >
> > sterling
> >
>
> Hi,
> From your earlier patches, it occurred to me that if we're
> going to go to this mod_perl.so convention, how about renaming
> all things that reference ApacheModulePerl, for consistency?
> For example, the attached tar.gz file, which unpacks into
> src/modules/win32/mod_perl.mak
> src/modules/win32/mod_perl.def
> src/modules/win32/mod_perl.dsp
> could replace the current
> src/modules/ApacheModulePerl/ApacheModulePerl.mak
> src/modules/ApacheModulePerl/ApacheModulePerl.def
> src/modules/ApacheModulePerl/ApacheModulePerl.dsp
> In these I incorporated your earlier patches to the .dsp
> and .mak files to build a mod_perl.so.
>
> This would mean some other changes; these are
> in the attached win32.diff file. To summarize,
> - Makefile.PL: use the src/modules/win32/* structure, as
> well as incorporating your patch to find the Apache lib
> in the new location for 1.3.15. This also will, according
> to the apache version, install mod_perl.so as mod_perl.so
> or as ApacheModulePerl.dll, if INSTALL_DLL is passed
> to Makefile.PL. Finally, a message is printed out at the
> end mentioning the new convention.
> - INSTALL.win32: mention the new convention, as well
> as change references from ApacheModulePerl.dll to
> mod_perl.so.
> - MANIFEST: changes the dsp file name
> - t/* files: makes some changes to load mod_perl.so,
> rather than ApacheModulePerl.dll.
>
> I tried this out on both apache_1.3.15 and apache_1.3.12,
> and it worked, but if you have a chance to try it ....
>
> best regards,
> randy
>
> ------------------------------------------------------------------------
> Name: win32.tar.gz
> win32.tar.gz Type: Unix Tape Archive (application/x-tar)
> Encoding: base64
>
> Name: win32.diff
> win32.diff Type: unspecified type (application/octet-stream)
> Encoding: quoted-printable
>
> ------------------------------------------------------------------------
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org

sweet, great work guys. the patch i have from randy seems to be truncated
(the tarball with mod_perl.{dsp,mak.def} looks ok though. sterls can you
send me the current patch against current cvs? thanks!

thanks, works like a charm. curious, should mod_perl.dsp be cvs add-ed
with -kb? i seem to recall cvs changing the file (stripping ^M's ?)
i also added mod_perl.def to the MANIFEST, we don't want to include
mod_perl.mak or do we?

ok, i've added it as a normal text file. randy, do you need to strip out
the ^M's ?

how does this work for you?

this includes my change to INSTALL.win32

sterling

Doug MacEachern wrote:

> sweet, great work guys. the patch i have from randy seems to be truncated
> (the tarball with mod_perl.{dsp,mak.def} looks ok though. sterls can you
> send me the current patch against current cvs? thanks!

> thanks, works like a charm. curious, should mod_perl.dsp be cvs add-ed
> with -kb? i seem to recall cvs changing the file (stripping ^M's ?)

welp, i've always had a problem when those ^M's are there - i don't think
that file should be binary - when i pull from cvs on win32 that .dsp file
(ApacheModulePerl.dsp) just don't work for me and never has...... so i
manually strip those things (well, with a script) and then all is well.

i vote checkem in as text files - (is there an issues with older versions
of msvc++? i'm useing 6.0)

>
> i also added mod_perl.def to the MANIFEST, we don't want to include
> mod_perl.mak or do we?

i don't think so, just the dsp. right randy?

--sterling

----- Original Message -----
From: "Doug MacEachern" <dougm@covalent.net>
To: "John K Sterling" <sterling@covalent.net>
Cc: "Randy Kobes" <randy@theoryx5.uwinnipeg.ca>; <dev@perl.apache.org>
Sent: Sunday, December 31, 2000 1:38 PM
Subject: Re: [PATCH] win32 module names now like unix


> ok, i've added it as a normal text file. randy, do you need to strip out
> the ^M's ?
>

Hi,
They are visible, but it built OK and passed all tests with them
there (using apache_1.3.15-dev). It probably would be better
without them, though ....

best regards,
randy

----- Original Message -----
From: "John K Sterling" <sterling@covalent.net>
To: "Doug MacEachern" <dougm@covalent.net>
Cc: "Randy Kobes" <randy@theoryx5.uwinnipeg.ca>; <dev@perl.apache.org>
Sent: Sunday, December 31, 2000 2:29 PM
Subject: Re: [PATCH] win32 module names now like unix


> > thanks, works like a charm. curious, should mod_perl.dsp be cvs add-ed
> > with -kb? i seem to recall cvs changing the file (stripping ^M's ?)
>
> welp, i've always had a problem when those ^M's are there - i don't think
> that file should be binary - when i pull from cvs on win32 that .dsp file
> (ApacheModulePerl.dsp) just don't work for me and never has...... so i
> manually strip those things (well, with a script) and then all is well.
>
> i vote checkem in as text files - (is there an issues with older versions
> of msvc++? i'm useing 6.0)
>
> >
> > i also added mod_perl.def to the MANIFEST, we don't want to include
> > mod_perl.mak or do we?
>
> i don't think so, just the dsp. right randy?
>
> --sterling

I agree about getting rid of the ^Ms - although it works for me
with them, it'd probably be better without them, as they can cause
problems.

I've always just used the .dsp file; the .mak file can always be
generated from the .dsp through Visual Studio, if need be.

Also, with src/modules/win32/*, we don't need
src/modules/ApacheModulePerl/* anymore .... This
may initially confuse some regular Win32 builders, but I
think between the message at the end of 'perl Makefile.PL'
and the fairly obvious names that most should figure it
out ....

best regards,
randy