On 2/17/22 02:39, jr wrote:
> chain-loading via 'file_exists()' is nice + "clean" (imo).
> 

I'm not completely sure I'm following what you mean by chain-loading?

I've adopted the use of file_exists() on deciding to ship a version.inc 
with povr. The overall implementation is done in a 
scene->version.inc->forkversion.inc way. Is this what you mean by 
chain-loading?

---
file_exist() is one of those things which is clean until it's not. :-)

Think about how we've often shipped binaries intended to run on a 
earlier install base. There is build infrastructure to support this 
model of update. A model somewhat workable because official POV-Ray 
supports backward compatibility. It's problematic in that to safely 
align with any given binary you need the binary's includes too - 
something that in POV-Ray proper requires a full install.

Think too about how the search path is user modifiable.

Anyhow, it's the method we have. I agree too for normal users with a 
single installation of POV-Ray, and relatively constant include files, 
file_exist is safe enough.

> 
>> ...
>> Comments welcome.
>>
>> Aside: I'm unsure when / if to change the povr code to force all
>> incoming SDL to run strictly at v3.8+. Internally, I've slowly been
>> tossing code for backward compatibility into the bit bucket. V3.8+ SDL
>> is all I intend to support. However, as many are still working with
>> older releases, scenes and includes, I've been maintaining the parser in
>> a state that allows earlier version settings. It's useful when looking
>> at posted issues...
> it would be interesting to see proposals for an updated v4+ SDL.

Practically, I don't think I've got the bandwidth for anything 
revolutionary in the povr fork.

It would probably be TCL if I do get around to trying something radical. 
I have a lot of that going today - as you know - but the implementation 
writes SDL. In other words, it still leans on the current SDL parsers.

> 
> out of interest, how difficult would it be to have two separate parsers?  one
> for pre 3.7/8 compatibility, one for newer style.  (I'm guessing that the
> executable would not be all that much larger, and separation might bring other
> benefits)
> 

My up front answer - difficult. The parser is still too integrated with 
the run time code. As something part of my povr branch it's not the most 
unattractive idea because it tangles me in two different parser 
implementations.

Aside: I've thought about hacking versions of POV-Ray in a way where 
they could be run as 'parse to some intermediate form and stop' 
utilities. And that thought reminds me I want to implement an actual 
#stop after parse directive. I use #error, but it's an ugly way to stop 
after the parsing stage.

Anyway, thanks for the ideas! As with the ini and options setting 
approaches, I'm still uncertain where the povr code will go.

> 
> have only spent a few minutes looking over the attached, seem ok (bar copy/paste
> typos 'str_var' in 'forkversion.inc'.)

Thanks. I believe that fixed.

And apologies. I must not of finished the editing of forkversion.inc (or 
somehow didn't do a last save...) I picked up a number of other mistakes 
'I thought' I'd fixed.

Bill P.

Post a reply to this message