From mboxrd@z Thu Jan 1 00:00:00 1970 From: msokolov@ivan.Harhan.ORG (Michael Sokolov) To: binutils@sources.redhat.com, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com Subject: Re: PATCH to top level: don't use dirname in configure Date: Sat, 22 Jul 2000 08:44:00 -0000 Message-id: <0007221542.AA29888@ivan.Harhan.ORG> X-SW-Source: 2000-07/msg00234.html Eli Zaretskii wrote: > This assumes that (a) $(progname) always expands to "configure", and > (b) that the last delimiter is '/'. I don't know whether the first > assumption is true on each supported system, but the second might be > wrong on DOS/Windows where a backslash might be used instead. Both of these assumptions are already being made extensively by the rest of the very same Cygnus configure script. The use of dirname there was actually out of line with respect to the rest of the script, and my patch makes it the same as the rest of the script. > In contrast, `dirname' (when it exists) will always DTRT, because it ^^^^^^^^^^^^^^ > is tailored to the host system. That's where the problem lies. As Alexandre Oliva wrote, : Unfortunately, `dirname' is too far from being portable. We must not : depend on its existence. GCC, Binutils, and GDB must be usable as add-ons to existing UNIX systems. At least one of these systems, 4.3BSD, doesn't have dirname. Therefore, the current top-level configure behaviour is unacceptable for GCC, Binutils, and GDB. My patch fixes an existing problem that must be fixed, and it cannot introduce new problems that didn't exist before (as it does the same thing the rest of the script does), therefore, it should be checked in. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) >From msokolov@ivan.Harhan.ORG Sat Jul 22 20:07:00 2000 From: msokolov@ivan.Harhan.ORG (Michael Sokolov) To: binutils@sources.redhat.com, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com Subject: Re: PATCH to top level: set MAKE=make on 4.3BSD Date: Sat, 22 Jul 2000 20:07:00 -0000 Message-id: <0007230304.AA20301@ivan.Harhan.ORG> X-SW-Source: 2000-07/msg00235.html Content-length: 660 > 2000-07-21 Michael Sokolov > > * configure.in (per-host: vax-*-bsd*): New special case. > * config/mh-vaxbsd: New file. I withdraw this patch. The Makefile framework in the entire Cygnus tree is broken beyond my ability to fix it, I had to give up and install GNU make. -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) >From eliz@delorie.com Sun Jul 23 04:01:00 2000 From: Eli Zaretskii To: msokolov@ivan.Harhan.ORG Cc: binutils@sources.redhat.com, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com Subject: Re: PATCH to top level: don't use dirname in configure Date: Sun, 23 Jul 2000 04:01:00 -0000 Message-id: <200007231101.HAA13289@indy.delorie.com> References: <0007221542.AA29888@ivan.Harhan.ORG> X-SW-Source: 2000-07/msg00236.html Content-length: 1152 > Date: Sat, 22 Jul 00 10:42:11 CDT > From: msokolov@ivan.Harhan.ORG (Michael Sokolov) > > Eli Zaretskii wrote: > > > This assumes that (a) $(progname) always expands to "configure", and > > (b) that the last delimiter is '/'. I don't know whether the first > > assumption is true on each supported system, but the second might be > > wrong on DOS/Windows where a backslash might be used instead. > > Both of these assumptions are already being made extensively by the > rest of the very same Cygnus configure script. Perhaps all of those places should be fixed not to use a literal "configure". > My patch fixes an existing problem that must be fixed, and it cannot > introduce new problems that didn't exist before (as it does the same > thing the rest of the script does), therefore, it should be checked > in. I didn't say the patch shouldn't be checked in (it's something for the maintainers to decide), I just pointed out a possible regression that could happen, in case it would be missed. This is what these forums are for. If there's no regression, or if the regression is deemed not important, it's fine with me.