Hi,
I just wanted to say, that I am still working on cmmi.
Up to now I did alot of Makefile.ams, that didn't work. But I start to
understand it, so I can ask some questions here:

The main idea was to GNUify the build process and directory structure as
much as possible. Just because people compiling software on UNIX are
probably more used to that than to the structure of povray on other
platforms.

So questions go into directory structure and building

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 ?

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.

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.

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.

As I work with automake and autoconf, GNU make will be required to build
povray, any problems there?

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?)

Axel

Post a reply to this message

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

Mark Gordon wrote:
> 
> Axel Hecht wrote:
> 
<...>
> 
> > 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?

Well, sorry. zlib would work, because it has a simple configure script,
but the building of libpng is almost more messy than the current povray.
So many scripts for all kind of platforms. We would end up with alot of
ifs, and never make it. 
We may have some --with-png=directory --with-zlib=directory though, and
use that for static builds. ?

 
> > 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?

The main reason is some trailing backslash every now and then, which is
a syntax enhancement of GNU make. But I can't find the exact thing in
the docs right now. And in my current version (only docs) it runs
through. We'll see.

> > 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


Axel

Post a reply to this message

There is a followup to this on povray.programming called
back from the automake badlands.

As it is mainly a programming question (reorganizing source) I moved it
over there. Posting is 2 days old, as I got more replies here (0 is
quite a minimum), I post this as a marker

Axel

Post a reply to this message