Date: Mon, 23 Jun 1997 19:48:17 -0400 (EDT) Message-Id: <199706232348.TAA27103@delorie.com> From: DJ Delorie To: broeker AT physik DOT rwth-aachen DOT de CC: djgpp-workers AT delorie DOT com In-reply-to: (message from Hans-Bernhard Broeker on Mon, 23 Jun 1997 17:05:45 +0200 (MET DST)) Subject: Re: Library rebuilds Precedence: bulk > I was a bit hesitant to do that because DJ had mailed me before, requiring > among other things: '4. Depends only on djgpp.' I simply wouldn't say that > Bash is already a 'part of djgpp'. Not yet. If it's on Simtel.NET, it's "part of djgpp". This requirement was to avoid the need for things like TurboC or other software packages that require the user to spend money or track down programs that aren't part of djgpp, and may not exist any more. The requirement does allow you to have a pre-built version of djgpp somewhere to get you started. > Well, it'd sure be a lot easier to get it machine-independant by using > Bash, but not everyone using DJGPP necessarily has Bash as well. Anyway, > if there's no serious objection, I think I will change to Bash. Not every machine can build libc from sources now anyway. As long as they can get it if they need it (I'd have to, for example), that's acceptable. > Well, I tried to not use more of the optional packages and ports than > necessary. That even includes fileutils, so I did not want to assume > existence of a 'cat' command on DOS. And this is only one of them. You may assume the user has any tool that is provided as part of the official djgpp distribution. If they don't "feel like installing it", then they aren't going to be able to build libc. Too bad. However, try to be reasonable. Using a tool just because it's neat is the wrong answer. For example, I convinced the FSF to avoid using awk, and use sed instead, because they already use sed in other places and there's no reason to require two tools when one would do. The same applies here. > So DJ's first requirement he mailed '1. Build everything from scratch in > one command' may actually be hard, or even impossible to do in every case. > But for normal situations, I have checkmarked that requirement as 'for > native builds: done' in my notes. It would be acceptable to have an alternate shell script to be used when cross compiling. This script could replace some make files, or use alternate ones, or fix them up, and could do what is needed for a unix-based cross compile. As long as it's one command and it's part of the source distribution, it's OK.