Mail Archives: djgpp-workers/2000/05/16/07:35:41
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.
- Raw text -