hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> > > ...
> > > Instead of using f_odd() to return additional patch/branch information,
> > > I think it should instead return always a value f_odd() cannot. For
> > > example, 99.0(a).
>
> > a macro to return a 'dictionary{}' would be real nice.  could have keys for the
> > changed stuff ("amplify") as well as version/patch level, everything in one
> > place.  :-)
> >
> Aside, or perhaps in addition to, what can be done under the hood,
>
> what if the versioning mechanism not only has internal functions, but checks for
> the existence of "versions.inc" in the path?  Preferably this would be a
> "wrapper" inc file that then looks for the most recent "versions_DateCode.inc"
> to use...

nice.  made me think there isn't a 'version.inc' yet, so, perhaps, one could be
added to all POV-Rays and variants[*].  standard .inc, only providing a macro or
variable that's true/false depending on whether official or not, and a way to
get info about which executable.  a variant like 'povr' or 'hgpovray' could then
simply add an '#include' in that file to load the specific stuff.  (_if only_
more/most of the code was in 'C'.  anyway :-))


[*] from 3.9 on, perhaps :-)

regards, jr.

Post a reply to this message