At the risk of stating the obvious, I think that the problem is that INSTALL is not a "real" target, it is a shorthand or "fake" target. I believe that some versions of make have a way of indicating that certain targets do not refer to real files, but I don't think that MMS/K support this - or do they? So perhaps all one can do is to document that the message is expected? [Note that one has to be careful that the fake target does not accidentally exist, otherwise it could prevent the actions from being executed ...] I haven't tried this, but it just might be possible to temporarily define INSTALL to point to a real file, so that it did appear to get updated, but it might be tricky to ensure that the definition was in place at the time when MMS/K was checking timestamps, and that it did not cause any actions to be skipped. -- Sebastian Bazley <[EMAIL PROTECTED]> The opinions expressed herein are my own, and are not necessarily endorsed by my employer ... > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: 12 May 2000 22:38 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: Perl 5.6.0 install errors > > > Craig A. Berry wrote: > > > Hmm. Here's the relevant snippet from descrip.mms: > > > > # install ought not need a source, but it doesn't work if one's not > > # there. Go figure... > > install : $(MINIPERL_EXE) > > @ @perl_setup.com > > If F$TrnLnm("Sys") .nes. "" Then Deass SYS > > $(MINIPERL) installperl > > > > It doesn't look like there are any file system objects to > the left of > > the colon. If we add a dependency, I wonder if we wouldn't want a > > dummy file that gets copied to the install directory at the end of > > the install rather than the Perl binary, which is one of the first > > things copied. That way a failed or interrupted installation would > > not report being up to date. Then we'd need to document that a > > reinstall should use MMK/FORCE or the user should delete the dummy > > file. > > That would be a much better way to do it. E.g. I am pretty sure > that the posix/unix Makefile tries to ensure that `make test` was run > before `make install` was attempted via the presence of a symlink in > the t/ directory. We could do something quite similar. > > Peter Prymmer > > ___________________________________________________________________________ This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Sema Group. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you have received this email in error please notify the Sema Group Helpdesk by telephone on +44 (0) 121 627 5600. ___________________________________________________________________________
