Date: Tue, 16 May 2000 14:52:12 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: "Mark E." cc: djgpp-workers AT delorie DOT com Subject: Re: Fw: DJGPP config changes part 2 of 2 In-Reply-To: <39204A70.12816.84C5F5@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody 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, 15 May 2000, Mark E. wrote: > The biggest change is > that it allows hosts to provide their own canonicalization routine to > update_path in prefix.c. DJGPP then uses this to canonicalize > '/dev/env/DJDIR/foo/bar/' to 'c:/djgpp/foo/bar/' (assuming DJDIR is set to > c:/djgpp). Previously, one would use something like 'sh ./configure -- > prefix=\$\{DJDIR}', but it's almost impossible for ${DJDIR} to survive > without being evaluated. Could you please explain why does GCC need to know about the /dev/env magic? After all, the library will do that for it when /dev/env is used in a file name, no? > + /* The default prefixes all use '/dev/env/DJDIR', so optimize \ > + for this. All other uses of '/dev/env/' go through \ > + libc's canonicalization function. */ \ > + if (strncmp (path + 9, "DJDIR/", sizeof ("DJDIR/") - 1) == 0) \ > + { \ > + if (djdir == NULL) \ > + { \ > + djdir = getenv ("DJDIR"); \ > + djdir_len = strlen (djdir); \ > + } \ > + memcpy (fixed_path, djdir, djdir_len); \ > + strcpy (fixed_path + djdir_len, path + 14); \ > + } \ Is this optimization really worth it? Its disadvantage is that it introduces a dependency between the library and GCC's sources, so if we ever change something in how /dev/env works, GCC might need to change as well. Unless the speedup is really significant, I'm not sure the price is justified.