Mail Archives: djgpp-workers/1999/08/30/11:17:10
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 -