Date:	Sun, 16 Jun 2002 08:33:05 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
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:	<Pine.SUN.3.91.1020616082445.26367E-100000@is>
MIME-Version:	1.0
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

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?

- Raw text -