Carl Bartels wrote:
> 
> Hello all,
> 
>   While playing with the mega-pov source I got annoyed by the fact that
> we have three different binaries to worry about and that compiling them
> in different order can give you different results...
> 
> make newunix ; make xwin   -will give you an x-povray binary that
>                             still just gives you ascii output.

There's a reason for that.

> make newxwin ; make unix   -will crash when compiling due to all the
>                             X-stuff scattered around the .o files.

There's a reason for that, too.  If the documentation suggests that's
OK, mea culpa.  If you are going to compile two different binaries (foo
and bar), the safe route is to make newfoo (which copies foocon.h to
config.h), followed by make foo only so long as you're compiling the foo
binary, and you need to make newbar (which clobbers the old config.h
with one copied from barcon.h) when you want to make bar binaries.  make
newunix still works because unixconfig.h is #included in each of
xwinconfig.h and svgaconfig.h.  If the actual POV-Ray code finds all the
libraries it needs for the new compile, the build succeeds (since it's
effectively still a generic console Unix build), just linked against
libraries it doesn't use and lacking the full functionality of the new
binary type.
 
> (never mind SVGA stuff for now)
> 
>   So I figured why not just make it all one executable with the
> following scheme (please comment on this)

Problem 1: If you don't have X libraries, I suspect the build will
fail.  I'm not sure how much of a problem this is, but I'd just as soon
avoid it.

Problem 2: Platform-specific binaries (e.g. SVGA) don't deal with this
well.  The current solution is more portable.

Granted, the current solution is less than ideal.
 
> Modify all the stuff in the unix directory so that we have a few extra's
> defined...
> 
> First off, just have one configuration file (only one binary) that has
> all the stuff for unix, xwin, and svga in it...one config.h

I have a cunning plan to make the config.h thing easier.  If I get it to
work, I'll share it ASAP, because I want to make sure it's portable.

>   I've decided to try to rig things so SVGA is more of a last resourt
> because a) I've hardly ever heard of anyone using it for anything if
> they had X around and b) there's a security problem with it (I think
> Mark Gordon pointed that one out.)

Agreed, SVGA is a last resort, and yes, I'm the one who raised the
security issues..  There's been some discussion of possible fixes that
don't leave us vulnerable to buffer overflows in the main body of the
code (it promises to be somewhat baroque).

While I'm on the subject of Linux-specific binaries, would anyone be
interested (assuming I can pull it off) in a framebuffer version of
POV-Ray?
 
-Mark Gordon

Post a reply to this message