|
 |
On 4/15/24 22:49, William F Pokorny wrote:
> The above said, the aim of this post is to document that I've found
> issues with ini parsing error reporting when ini files are directly
> included!
I believe these issues now fixed in the upcoming release R14 of yuqk.
> ...
> Because it's part of the 'ini' tofix pile and related, I'll toss out
> again that the ini directory ordering, as affected by library paths, is
> glitch-y. We should not be using the library search paths for ini files
> at all, but rather only for include files.
>
> It believe it should always have been another path set up mechanism for
> ini files (perhaps an INIPATH env var similar to PATH?). Or, no path
> searching at all and just include_ini= or +ini usage. This latter
> approach is how I plan to go with yuqk - though I've not yet worked out
> the code changes to disable to sometimes searching of the library path
> for ini files, so we'll see.
And with the library paths in v3.8+ onward(*); the problem with the ini
search mechanism only picking up the first search directory in the set
has been fixed for release R14 of yuqk.
While there are other fixes / changes in yuqk besides, I 'think' much
can be had in official v3.8+ POV-Ray releases by simply adding the line:
libpath.clear();
just ahead of:
if (POVMSAttr_GetUTF8String(&item,kPOVMSType_UCS2String,libpath) != 0)
in:
ITextStream *ProcessRenderOptions::OpenINIFileStream(...)
in the file: source/frontend/processrenderoptions.cpp
Things go wrong in POVMSAttr_GetUTF8String() and the collection of
functionality it calls in that the individual paths returned after the
first are mangled / blended with prior results.
I've kept the now working library path searching in yuqk rather than
create an alternate approach / method for it - though I think any
eventual v4.0 offering should set up a separate 'ini path'.
(*) - The v3.8+ code is different than the v3.7 code. Unsure how v3.7
works with respect to ini files and searching the specified library path.
Bill P.
Post a reply to this message
|
|
