Message-ID: <3992A575.DD7D7B9D@maths.unine.ch> Date: Thu, 10 Aug 2000 14:52:04 +0200 From: Gautier Organization: Maths - Uni =?iso-8859-1?Q?Neuch=E2tel?= X-Mailer: Mozilla 4.74 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.os.msdos.djgpp Subject: Re: DJGPP neither running on ms-dos 6.2 nor on caldera-dos 7.03 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NNTP-Posting-Host: mac13-32.unine.ch X-Trace: 10 Aug 2000 14:52:07 +0100, mac13-32.unine.ch Lines: 41 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com > > The names are "crunched", e.g. for extreme cases > > a-chahan.ads -> Ada.Characters.Handling > > a-llfwti.ads -> Ada.Long_Long_Float_Wide_Text_IO > > a-exctra.ads -> Ada.Exceptions.Traceback > > i-os2thr.ads -> Interfaces.OS2Lib.Threads > > When built for DOS, GNAT will search for crunched 8.3 names Eli: > GCC has a similar facility for remapping the header files (see the -remap > option to GCC). We use it to deal with the String.h vs string.h problems. > However, the mapping file is crafted by hand, so this solution is > error-prone (the person who ports GCC might simply forget to prepare > the file, or miss a few headers which need remapping). I also am not > sure whether this works for libraries and other files. > In other words, if this feature isn't part of the standard build, it > is IMHO not a good solution to the problem at hand. The name crunching algorithm of GNAT is completely automatic, following precise rules (with the exception of "a-", "g-" etc. for standard packages). There is no remapping file. The algo is very efficient (i.e. almost never 1 short name for 2 long names) even for some rather long-winded standard Ada packages names (children units etc.), so I think it could _a fortiori_ work in a context where the names are rather short. As for the compilers's behaviour, it is very simple: if a source uses SVGA.Effects, the compiler will search for the file svgaeffe.ads as Krunch tells it, for SVGA.Effects.IO, it will look for svgeffio.ads and nothing else, and so on. Of course the inter-unit inlining option or the automatic make utility does the same for unit bodies (.adb), allowing a full recompilation - but it's another story. You find the method in "krunch.ads", "krunch.adb" files in the GNAT sources, with explanations and comments. It could help things I think... ______________________________________________________ Gautier -- http://members.xoom.com/gdemont/gsoft.htm