 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
make newxwin ; make unix -will crash when compiling due to all the
X-stuff scattered around the .o files.
(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)
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
#define NO_XWIN NO_XWIN - in the config.h file to let people decide not
to compile in X support. (comment out by
default)
#define NO_SVGA NO_SVGA - dito for SVGAlib support. (define by
default)
if NO_XWIN and NO_SVGA are both defined then don't compile X or SVGA
stuff and define the +D or +D0 switch to give the ascii display.
if only NO_SVGA is defined, leave out SVGA stuff from the compile and
have +D or +D0 use the X-display if it exists, but fall back on ascii.
Define the +D1 switch to use an ascii display.
if only NO_XWIN is defined, leave out XWIN stuff from compile and have
+D or +D0 activate a SVGA display while +D1 would give you ascii.
if none are defined, then compile in everything, and have the following
switches...
+D, +D0 check for an X display, but fall back on ascii if none exists
+D1 use ascii
+D2 use SVGA
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.)
My apologies to anyone who does use SVGA.
Now, all I have to do is figure out how to put all that together. I
think I found myself a Christmas project.
Thanx for any comments on this.
--
Carl Bartels, Department of Chemsitry, Mcgill University, to reply to
me,
just kill a and 5 from the email name, Montreal, QC, cAnAdA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Carl et al.,
in addition to Marks reply I have some things to note.
The binary Carl suggested would be great, but it won't work with the
current 'hooking' in povray. I discovered this in my attempt to do a
configure'd build.
Hooks (like the display-routines) are done by #define in povray. This is
ok for the current build-process, but anything changing this to be more
straightforward has to change that. And then it's not just a unix
problem anymore.
And another essential problem is, that there is just on hook for
display, and making a single binary can't cope with that. You can't
define the display routine to be both X and SVGA.
I just came upon a trick: #define the hooks to be dummy functions, that
are assigned to real function pointers on runtime. The unix-hooks could
stay as they are, just the display-hooks have to be assigned on runtime.
They could go to 'nothing' (for console), X or SVGA. The set of
available choices could be done with #ifdef and a -DHAVE_LIBX on the
compile line. (This looks close to autoconf right now).
But would this impose special linux commandline arguments? To choose X
or SVGA? Not so happy about that.
Getting this straight is the key to a configure;make;make install;
build. But perhaps Mark knows all about the feelings of the POV-Team
about the hooks.
Axel
PS: Should this thread end in povray.programming? Set followup as you
whish.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Carl
One binary sounds like progress to me.
--
Cheers
Steve email mailto:sjl### [at] ndirect couk
%HAV-A-NICEDAY Error not enough coffee 0 pps.
web http://www.ndirect.co.uk/~sjlen/
or http://start.at/zero-pps
1:27am up 1 day, 2:48, 7 users, load average: 1.12,
1.22, 1.25
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
