delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/08/30/11:17:10

Date: Mon, 30 Aug 1999 17:07:00 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Laurynas Biveinis <lauras AT softhome DOT net>, Andris Pavenis <pavenis AT lanet DOT lv>
cc: DJGPP Workers <djgpp-workers AT delorie DOT com>
Subject: Re: symlink() & is_v2_prog() question
In-Reply-To: <37CA7A1F.B5219B90@softhome.net>
Message-ID: <Pine.SUN.3.91.990830165106.1411D-100000@is>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Mon, 30 Aug 1999, Laurynas Biveinis wrote:

> I think symlinks would make porting GCC easier, well, Andris knows better,
> but in readme.DJGPP for gcc-2.95.1 it is said:
> 
>    in such parts Win95 DPMI server can take. Second reason was to
>    simulate bootstraping gcc which was impossible in other way due to
>    absence of fully functional symbolic links.

Usually copying should fix such problems.  Andris, if "ln -s" would copy 
files that aren't executables, would the above problem still exist?

> > Also, `stat' needed a lot of changes and improvements before we got it
> > right.  But while `stat' was introduced together with DJGPP v2.0, which
> > was new and therefore was supposed to have grave bugs, we are now in
> > v2.03, where core functionality is supposed to be stable.
> 
> What will be after 2.03, 2.04 or 2.1?

No, I meant that we shouldn't get anywhere near the v2.0 status in future
versions at all.  When v2.0 was released, there were several people who 
actively developed DJGPP and who understood very well the intricacies of
the DJGPP environment.  I don't expect that to be true in the future.

Call me a coward.  I'm afraid to break a good thing that DJGPP is now.

> Symlinks would be OK for 2.1, and
> there will be enough time for testing their stableness.

I don't worry about how stable the symlink support will be: this is an 
additional feature, so if it is broken, people have the option of not 
using it as they do now.

What I'm afraid is how bad will this destabilize the library.  Rewriting 
a lot of core functions will introduce bugs that have nothing to do with 
symlinks.

> OK, a technical question - I have character string (symlink file prefix)
> which is used in two source files. Should I put it in <unistd.h> as
> _DJGPP_SYMLINK_PREFIX or create internal include file, just like xstat.h? 

Internal headers are for something that is not meant to be used by 
application code, ever.  If you think that several unrelated library 
functions will need to know about the prefix, put it on some header in 
the include/libc directory, for example <libc/symlink.h>.  Public
headers such as unistd.h should not hold symbols that are private to
the library implementation; we should keep the namespace clean.

But if you think application code will need to know about the prefix, 
then put it into unistd.h.

> How about that utility which created symlink? If programmer uses symlink()
> instead of some file copy routine, then he/she may expect something.

If `symlink' is going to be used extensively, that's a possibility.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019