[m-rev.] for review: document workaround for bug #303

[Julien Fischer]

On Fri, 22 Nov 2013, Peter Wang wrote:

> On Fri, 22 Nov 2013 17:25:17 +1100 (EST), Julien Fischer <jfischer at opturion.com> wrote:
>>
>> For review by anyone.
>>
>> For the 13.05 release I intend to simply document this issue.  In the
>> longer term we should:
>>
>> (1) not generate such enourmous Java class names
>
> shorten_long_class_names tries to do this (the filename component
> anyway) but could be more conservative.

The class name that causes the issue is:

     fat_sparse_bitset$S_TypeSpecOf__pred_or_func__do_foldl2_pred___T_a484fdff_do_foldl2_pred___T___var_V_2___4_1_6_p_4_env_0.class

(The problem is caused by the fact that the directory component of the
fully qualified name of the above is also quite large.)

One other thing we could do here that would help is change the name
mangling scheme used by the compiler for introduced names, e.g. why not
s/__pred_or_func__/__pf__/ in the above etc?

Another thing that would help here is if the build system allowed to
specify a build directory that was different from the source directory.

>> @@ -95,6 +95,23 @@ Java compiler, but we haven't tried that yet.
>>
>>   -----------------------------------------------------------------------------
>>
>> +BUILDING THE JAVA GRADE ON WINDOWS
>> +
>> +When building the Java grade on Windows it sometimes possible for the fully
>> +qualified names of some generated files to exceed the maximum path length.
>> +If this occurs the Mercury compiler will abort with a message like:
>> +
>> +   Uncaught Mercury exception:
>> +   Software Error: parse_tree.module_cmds: predicate \
>> +   `parse_tree.module_cmds.list_class_files_for_jar'/6: \
>> +   Unexpected: io.file_type failed: No such file or directory
>> +
>> +In this case all that can (currently) be done is to reduce the length of the
>> +build path, for example by shifting the build directory closer to the root of
>> +the file system.
>
> e.g. c:\m

Done.

Cheers,
Julien.