Date: Sun, 16 Jun 2002 08:33:05 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: sandmann AT clio DOT rice DOT edu cc: djgpp-workers AT delorie DOT com Subject: Re: Clio 2.04 packages In-Reply-To: <10206151751.AA18505@clio.rice.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Sat, 15 Jun 2002 sandmann AT clio DOT rice DOT edu wrote: > > requires all ports to be relinked, otherwise a combination of old and > > new binaries will be subtly broken. > > I'm not sure this is as much of a problem as is stated here. Any symlinks > would be unusable by old images - but they would also be unusable by > any non DJGPP toolchain program. So, I don't believe this is that big > an issue I didn't say it was a big issue; note the ``subtly'' part. I just don't like subtle misfeatures. > and I don't believe symlinks will be used that much since they > aren't supported by the base OS or other tools. Every configure script uses "ln -s", and many Makefile's do that as well. Enable symlinks, and you will have them soon enough, believe me. > (I wasn't around during the development, and haven't read the back > discussions on this, so forgive me if this has all been covered... > Why wasn't something like windows .lnk format chosen? The Windows .lnk format would not solve many problems, since Windows doesn't support shortcuts in all file-oriented system calls. And there's the case of DOS, of course. > Why remove the old EXE stubing type symlink It wasn't removed, it's still there. > how to run these from command prompt? Like we do now, with the stub-level ``symlink''. > > Please note that rebuilt packages should be at least reconfigured and > > sometimes will need source changes due to the symlink support. > > Why? They need to be reconfigured because the configure-time test for symlink support will now succeed; we want that to enable the parts of code which need symlink support. Some packages will need more than just reconfigure and rebuild because the code which depends on symlink support was never made to work with DJGPP, so it could fail due to the ``usual'' reasons (slashes, letter-case in file names, drive letters, etc.). > Because of non-DJGPP tool chain support I would suspect we would > want to minimize symlink use to portability/testing support. Sure, but you still want "ln -s" to produce a symlink, don't you?