Support relative file Paths for parseFileHeader

[tschierz]

Problem
OpenCRG supports master .crg files that reference other .crg files via relative paths. Currently, these paths are resolved relative to the current working directory (CWD) rather than relative to the master .crg file's location. This breaks file references whenever the CWD differs from the master file's directory - which is the common case.

Expected behavior
Relative paths in a .crg file should be resolved relative to the directory containing that .crg file, consistent with how most file formats (e.g., XML, CMake, HTML) handle relative includes.

Proposed fix
When loading a master .crg file with parseFileHeader() in crgLoader, derive the base directory from the master file's path and resolve any referenced relative paths against that base directory instead of the CWD.

[jorauh]

Thanks for asking about the FILEREF feature, which is similar to INCLUDE features known from other standards, but in OpenCRG limited to only allow replacing or adding modifier and/or option sections of the referenced .crg file containing the data.
The documentation of this feature will be fixed in v2.0.1 (#59) to be consistent to previous documentations, existing implementations and the samples in crg-txt/fileref*.crg .

The currently implemented behavior might differ from some INCLUDE implementations, while some other just do it as OpenCRG - by using the CWD as reference for relative paths.

Your proposed change would break version compatibility, So I suggest to take this issue as feature request, to additionally implement some way to take the current file's location as reference for relative paths. Any suggestions on how this additional feature could be labeled are welcome.

[CarawaySeed42]

An idea to discuss or to at least keep in mind.

At the moment system/user environment variables can be used in the referenced file's path, e.g. $ENVVAR/folder/file.crg.
If this environment variable does not exist, it is replaced with an empty string.

The OpenCRG API could define LOCAL environment variables, that can be used to control the fileref behaviour.
For example:
OpenCRG API defines $OPENCRGFILEDIR as the path to the current CRG file and $OPENCRGCWD as the path to the current working directory.

-> $OPENCRGFILEDIR/folder/file.crg would be resolved as a relative path from the CRG file's directory containing the file reference to another CRG file.

This would not break backwards compatibility, because the old OpenCRG versions can not resolve these environment variables and they would result in an empty string, which would then result in the previous/current behaviour.
Assuming, of course, that the local environment variables do not already exist as system/user variables. But even then, the behaviour remains as it was intended.

This new behaviour regarding local environment variables then needs to be documented and there needs to be clear restrictions, what variables can be used and how they are named to avoid collisions.

Of course, all of this only makes sense, if backwards compatibility needs to be kept.