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 -