On Apr 6, 2005 12:47 PM, Michael G Schwern <[EMAIL PROTECTED]> wrote: > On Wed, Apr 06, 2005 at 11:36:44AM +0200, demerphq wrote: > > Just so you know this isnt true with the Win32 makefiles at all. From > > perl/win32/Makefile i have extracted distclean and realclean: > > Win32's distclean looks like its doing a lot of what MakeMaker's realclean > should already be doing. Its possible this is an old work around for old > MakeMaker bugs. > > You might want to try a "make realclean" and then do a distcheck to see > what's left around. Its possible MakeMaker has already done the job.
Im pretty sure that distclean is in some situations required. For instance if headers are updated in the perl root they arent necessarily copied over to the CORE directory as part of the standard build process. Until I hacked the makefile to _always_ start by updating CORE as appropriate I had problems that only distclean would fix. > > Also even the core's distclean is different from MakeMaker's so I wouldn't > worry about brining Win32's Makefile in line with MM, just remove the > bits that are duplicating Extensions_realclean. > > # relevent part from the core Makefile. > _clobber: > [EMAIL PROTECTED] -f Cross/run-* Cross/to-* Cross/from-* > rm -f config.sh cppstdin Policy.sh extras.lst > > clobber: _realcleaner _mopup _clobber > > distclean: clobber Personally I have been thinking a lot about a "single win32 makefile" solution. We have issues with ensuring that Makefile.mk and Makefile are in synch with each other, (aside from the issue of synching them with what MakeMaker does, or what the Configure script does on *nix). We have missing targets between the makefiles, and we have slightly different handling inside of them. The documentation in most cases in *nix specific and its only by trolling the particular makefile you are using that you can tell what is going on. Even worse we have a history (going back in my memory to at least Sarathy under 5.6) of making sure that the Makefile only uses LCD features of the various Win32 OSes and shells. This for instance means that the /y modifier is omitted from the /.COPY/ targets which use xcopy, meaning you cannot nmake twice in a row without being asked a zillion questions during the second make. Likewise we see hacks like calling rd twice in a row with different options. All of this just in case somebody builds for 98/ME/95? IMO we should either drop support for buildng on them, or at least come up with a solution that allows the vast majority of us developing core on win32 to use the features of the os'es we are on. If some Win9x developer surfaces then let them maintain the makefile. :-) What id love to see (and would work on if the community thought it was worthwhile) is a single makefile with some tools to convert it for the appropriate Win32 OS/maker combination. IMO there isnt a lot of chance that anyone will be building perl on a win32 system without already having an earlier Win32 perl installed, so a script that handles it would do the trick. Anyway, do please bear in mind im only talking about blead here... Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
