Date: Mon, 30 Aug 1999 17:07:00 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Laurynas Biveinis , Andris Pavenis cc: DJGPP Workers Subject: Re: symlink() & is_v2_prog() question In-Reply-To: <37CA7A1F.B5219B90@softhome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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 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 . 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.