On Mon, 19 Mar 2001, Brian Ingerson wrote:
> If filename lengths are a problem, this is a showstopper (at least for
> now). It's not just the temporary files that have long names. The final
> "installed" executable also has a very long filename. For example a
> executable called Foo normally gets installed as:
>
> /some_perl_lib_path/auto/Foo/Foo.so
>
> If '/some_perl_lib_path/' is in @INC, Perl can find the executable.
> Since my names have md5 keys in them, I need to install the modules as:
>
>
>
>/some_perl_lib_path/auto/Foo_C_033f0bc5ea371715666063f485f4d4b2/Foo_C_033f0bc5ea371715666063f485f4d4b2.so
>
> Luckily, I have plans to change all that by putting the md5 key in a
> separate file like this:
>
> /some_perl_lib_path/auto/Foo/Foo.so
> /some_perl_lib_path/auto/Foo/Foo.inl
>
> The '.inl' file will contain all of the Inline required meta data, like
> md5 key, and external dependencies, and binary compatibility info.
>
> I have this all planned out, but with my current schedule, I don't see
> it being finished until mid to late April.
This sounds like an excellent design idea. FWIW there already is an
analog of this idea on VMS: the ld utility needs to link together very
long strings of individual files specs _but_ the shell imposes a 512
character limit on command lines. The solution in that case is for the
linker to take the name of an extra options file with a default name of
Foo.opt then link against all the things listed within the Foo.opt file.
Your Foo.inl file sounds like a similar plan.
Peter Prymmer
