POV-Ray : Newsgroups : povray.unix : Update/questions on configure;make;make install; : Re: Update/questions on configure;make;make install; Server Time
28 Jul 2024 18:11:54 EDT (-0400)
  Re: Update/questions on configure;make;make install;  
From: Mark Gordon
Date: 1 Oct 1999 08:44:26
Message: <37F4AD42.FFD89D7A@mailbag.com>
Axel Hecht wrote:

> Where should the ini's go?
> $prefix/etc/povray or $prefix/share/povray/ini
> (All includes go to $prefix/share/povray and scene is a subdirectory
> there.)
> xpovicon.xpm to $prefix/share/icons ?

I'm inclined to hedge and put the default povray.ini in
$prefix/etc/povray and all the others in $prefix/share/povray/ini. 
povray.ini is a system-wide default if nothing else is specified, so an
etc directory makes sense for that one, but I don't think it makes sense
for any of the others.  If there's an ini specific to a scene, it should
be in the same directory as the scene.  My $.02, anyways, unless someone
else points out a reason that this might be dumb.
 
> More important, how many work should be done for the scene tree. As this
> is X-platform, most changes won't make it anywhere, so a lot of work
> won't pay, right? On the other hand, substituting all-scene.sh with
> 'make check' would offer parallel execution, and I remember that one
> scene did not work because of dependencies.

That depends on what people are using all-scene.sh for.  POV-Win uses
scenes/incdemo/shapes.pov (at least, that's where that scene is under
Unix) for a post-install test; we could just render that for 'make
check' and keep allscene.sh as it is.  What do people think?

As for dependencies, you're thinking of crater.pov, which uses
crat_dat.png as a height field.  I've been meaning to fix all-scene.sh
so that it handles the dependency more gracefully.  One method would be
to turn it into a makefile (I would need to make it abundantly clear in
a README that it's not used for compilation; maybe I'll make life easier
and put it in a 'test' subdirectory or some such).
 
> I have to revamp the build process, because there are too many targets
> right now. I figured how to do it, but that would mean, that config.h
> would be one file depending on -D switches of the compile step.

I'm not terribly surprised.
 
> For now I left out the sources for libpng and zlib competely, as most
> unix-folks have them. Also multiple sources and configures are rarely
> done in GNUified builds.

Not all Linux distributions have these, and not all have current
versions.  Might it be possible to check whether they have libpng and
zlib already and build them iff they don't?
 
> As I work with automake and autoconf, GNU make will be required to build
> povray, any problems there?

Hmm.  Could we check the version of make with the configure script and
use a default tweak-it-yourself makefile if they're not running GNU
make?

Feedback from others? How many people aren't using GNU make?
 
> You see, alot of work with (I think) good reason, but I probably won't
> do it, if everything has to be done again for the next version (Mark?)

I'd like to see something along these lines tested openly (broad variety
of platforms is vital for this, IMHO), and it's easiest to do that with
3.1 at this point.  If you're too busy, I can work on this myself, but
I'm looking forward to user feedback on this.

-Mark Gordon


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.