On 6/13/05, demerphq <[EMAIL PROTECTED]> wrote:
> On 6/13/05, vadim <[EMAIL PROTECTED]> wrote:
> > > >Change 24806 by [EMAIL PROTECTED] on 2005/06/12 09:54:07
> > > >
> > > >     Subject: improve static build for win32/Makefile
> > > >     From: vadim <[EMAIL PROTECTED]>
> > > >     Date: Sun, 12 Jun 2005 14:09:11 -0400
> > > >     Message-Id: <[EMAIL PROTECTED]>
> > > >
> > > I guess it serves me right for not being around at weekends, but I wish
> > > this hadn't been committed in my absence.  Did you try this on Win32
> > > before committing?
> > >
> > > I've long meant to have a look at a problem with the static build stuff
> > > in win32/makefile.mk but have never had time to get around to it.  The
> > > problem is that $(PERLDLL) depends on Extensions_static, which is a
> > > pseudo-target -- there is no file of that name -- hence make always
> > > considers it to be out-of-date.
> > >
> > > Now the win32/Makefile has the same problem :(
> >
> > Well, this is due to my limited understanding of nmake (and dmake).
> >
> > While trying to fix broken things (those STATIC_EXT and DYNAMIC_EXT are
> > for years, and were not working, even related C code was broken) I
> > introduced a problem.
> >
> > Could you please advice on a good way to fix?
> >
> > May be it is reasonable to create a real empty file with that name?
> >
> > Also, how it is possible there is no problem with pseudo-targer
> > "Entensions" but there is a problem with "Entensions_static"
> 
> Timing. It happens at the wrong time. 
>
> Give me 10 minutes and ill post a patch that sorts things out. Im just
> resynching as i forgot to copy the tree before I put together my
> patch.

Double /grr as the rsynch seems to have introduced a seperate
unrelated problem, and the patch i thought would sort it all out
doesnt work as expected.

However, the attached patch will at least get the smokes running
properly by preventing the "do you want to overwrite" question in
xcopy.

Incidentally this change has been proposed before _several_ times
(adding /y to the xcopy) The reason it was rejected in the past is
that the /y isn't supported on Win9x/Me, but i think its safe to say
that nowadays there isnt anybody building perl on those OS'es, and
frankly if one does pop up they can remove the /y instead of forcing
everybody who DOES actively build perl on Win32 to add the /y
themselves. (I beleive there are several people build perl regularly
under Win2k and WinXP which does support the /y, why penalize them
when there isnt any sign of anybody building on those OS'es?)

Of course it doesnt resolve the problem that all of the extensions are
relinked, but that is just a PITA and not a showstopper like the xcopy
problem.

Cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Attachment: fix_static.patch
Description: Binary data

Reply via email to