Can't export FMUs of Buildings Library under Windows because of pathname length limitations

[casella]

Steps to Reproduce

Try to export any runnable model of the Buildings Library as an FMU using OMEdit, e.g. Buildings.Examples.ChillerPlant.DataCenterContinuousTimeControl. The following error is obtained

CMake Warning in CMakeLists.txt:
  The object file directory     D:/Temp/OMEdit/Buildings.Examples.ChillerPlant.DataCenterContinuousTimeControl/Buildings_Examples_ChillerPlant_DataCenterContinuousTimeControl.fmutmp/sources/build_cmake_dynamic/CMakeFiles/Buildings_Examples_ChillerPlant_DataCenterContinuousTimeControl.dir/   
has 257 characters.  The maximum full path to an object file is 250  characters (see CMAKE_OBJECT_PATH_MAX).  
Object file external_solvers/dgetf2.c.obj   cannot be safely placed under this directory.  The build may not work
  correctly. 
...
CMake Error in build_cmake_dynamic/CMakeFiles/Buildings_Examples_ChillerPlant_DataCenterContinuousTimeControl.dir/DependInfo.cmake:
  cmListFileCache: error can not open file. 

How to address this issue

We have solved similar problems regarding long pathnames and filenames containing Unicode characters by enabling 8.3 filenames; another untested approach is to use UNC pathnames, #8838, which may not be supported by CMAKE handles them.

One thing we can do easily is the same that we already did for the C runtime: shorten unnecessary long pathnames!

OMEdit places all the files in a subdirectory of the working directory which is named as the full pathname of the model. That's OK in order to avoid overwriting stuff related to classes with the same name but on a different path.

But then, it generates a temporary directory inside it to generate all the FMU stuff which is again using the entire pathname, e.g. Buildings_Examples_ChillerPlant_DataCenterContinuousTimeControl.fmutmp. This is completely
unnecessary, fmutmp or even just tmp would do. There is no risk of aliasing, since this directory is already contained in a directory with the full class pathname.

Ditto for all the paths and files that are contained therein: there is no need to have source code files like Buildings_Examples_ChillerPlant_DataCenterContinuousTimeControl.c, DataCenterContinuousTimeControl.c would do equally well. We already do that when compiling for the C runtime and everybody's happy with it.

Even further, the .fmutmp directory contains sources/build_cmake_dynamic/CMakeFiles, which again contains a directory with the full pathname Buildings_Examples_ChillerPlant_DataCenterContinuousTimeControl.dir. Once more, no need to use the full pathname there.

If we do so, the pathname D:/Temp/OMEdit/Buildings.Examples.ChillerPlant.DataCenterContinuousTimeControl/Buildings_Examples_ChillerPlant_DataCenterContinuousTimeControl.fmutmp/sources/build_cmake_dynamic/CMakeFiles/Buildings_Examples_ChillerPlant_DataCenterContinuousTimeControl.dir/, which is 257 characters long and therefore beyond CMAKE's limit, would become D:/Temp/OMEdit/Buildings.Examples.ChillerPlant.DataCenterContinuousTimeControl/tmp/sources/build_cmake_dynamic/CMakeFiles/DataCenterContinuousTimeControl.dir/, which is only 157 characters long and would work out of the box with a lot of margin.

I understand this may not be the final solution to all such problems, but I guess it's a very easy fix to implement.

@adrpo, @arun3688, @AnHeuermann, @mahge, who can take care of that?

Thanks!

Related issues

See also #8838 and #9508.

Keeping @Pavanrajhr and @deepak19015 in the loop.

[casella]

In fact, we could just use "sim" or "foo" or "exec" or any other short name. There is no risk of name clashes because these files are already contained in a directory with the full model pathame.

[casella]

See also OpenModelica/OpenModelicaLibraryTesting#46.

[t-sommer]

FWIW most commercial tools use the model name w/o the path for the FMU's filename and binary.

So for Modelica.Mechanics.Rotational.Examples.CoupledClutches you would get CoupledClutches.fmu with binaries/win64/CoupledClutches.dll which usually avoids long paths.

[adrpo]

After merging my changes now buildModelFMU(Path.To.Model) will generate Model.fmu instead of Path.To.Model.fmu.
This should remove some of the issues with long paths.

[casella]

Thanks @adrpo! I'll test ASAP with the latest nightly build. If it works fine, then you can port it to maintenance/v1.22 and we can close this.

[casella]

Just tested with Buildings.Examples.ChillerPlant.DataCenterContinuousTimeControl, I generated the FMU successfully.

Please cherry-pick to maintenance/v1.22 and close this ticket.

[casella]

Merged into maintenance/v1.22