In a hybrid workspace (repo access from Windows, compiling in Windows and in a VM running Linux), the dbdToHtml.pl tool on Linux fails the build when the source file has Windows line endings:
> perl -CSD /home/ralph/work/EPICS/V3/3.15/md-epics-base/bin/linux-x86_64/dbdToHtml.pl -I. -I.. -I../O.Common -I../../../src/ioc/as -I../../../src/ioc/bpt -I../../../src/ioc/db -I../../../src/ioc/dbStatic -I../../../src/ioc/dbtemplate -I../../../src/ioc/misc -I../../../src/ioc/registry -I../../../src/ioc/rsrv -I../../../dbd -o menuConvert.html ../../../src/ioc/bpt/menuConvert.dbd.pod
> ' in ../../../src/ioc/bpt/menuConvert.dbd.pod POD directive
> ../../../configure/RULES.Db:431: recipe for target '../O.Common/menuConvert.html' failed
> make[3]: *** [../O.Common/menuConvert.html] Error 25
> make[3]: Leaving directory '/home/ralph/work/EPICS/V3/3.15/md-epics-base/src/ioc/O.linux-x86_64'
While this mode is obviously not the most common case, this EPICS tool should be robust enough to handle both line ending styles - all other used tools do not have such issues.
There are a number of regular expressions in the dbdToHtml.pl script that match POD directives in the input file. If the Perl interpreter's newline sequence doesn't match what's in the file, the string being matched may contain extra white-space characters. In several cases the captured strings are supposed to be record type, menu or field names, and the script dies if it can't find the associated object.
The attached patch changes the regular expressions to exclude trailing white-spaces from the capture patterns so should fix this issue. Please test and confirm.