On Mon, 10 Feb 2003 02:08:13 +0100, Nicolas Calimet wrote:

> 	Hi all,
> 
> 	The current auto-configuration scheme for POV-Ray (3.50c) is
> undoubtly targetted towards Linux and gcc, which means a lot of its
> initial potential is simply lost. The ./configure script and related
> facilities were initially prepared by Mark Gordon for the UNIX version
> of the first 3.5 release. As he mentionned in the docs, it was his first
> trial with those GNU tools, and it proved to work well on Linux
> architectures. However, since then all other *nix platforms have been on
> their own.

Well, Linux is the only system to which I have unfettered access.

> 	This is my attempt to make things evolve in this field. While
> I already know there is room for improvement (see below), I post it
> right now so that as many UNIX people as possible try it on their own
> platform(s).

Thanks, I'd been hoping for input on this.

> 1) Any compilation flag is now checked at configuration time instead
>     of being hard-written in the Makefile.

This had been on my todo list...

> 2) The src/optout.h file is modified automatically so that no hand-
>     editing is required for updating the DISTRIBUTION_MESSAGE_2 field.
>     This message is for now setup as "user@machine".

Something like this had been on my todo list.  More commentary below.

> 3) A --disable-shared option is added for linking with static libraries
>     instead of shared libraries (default).

This had also been on my todo list.
 
> INSTALL
> =======
> 
> 	The configure script has been reworked with the last autoconf
> (2.57) and automake (1.7.2) versions (but in principle you don't need
> them on your systems). Several supporting files are also provided, so
> the whole stuff is given as a .tar.gz file. You will need a **clean**
> povray-3.50c distribution.

Are you willing to submit bits of this to the official version?  License
problems prevent me from borrowing too freely from most auto*-using apps.
Your "missing" script is GPL.  I'm not sure of the implications of having
GPL scripts distributed for the purpose of building non-GPL-compatible
software, so I've generally avoided it.

I'm currently disting on a box that has older versions of autoconf and
automake (which may be problematic, dunno yet).  Hopefully that wouldn't
be a major problem.

> KNOWN PROBLEMS AND FUTURE WORK
> ==============================
> 
> * Libpng seems to be an issue at least on IRIX. This configure script
> needs
>    the lastest libpng-1.2.5 to work. Maybe 1.2.3 and 1.2.4 will work
>    too, but I didn't test them. Older versions might fail when linking.
>    At test must be added to detect which version is installed and which
>    library name to link with. For now povray is linked with -lpng12 (not
>    -lpng).

Makes sense.  If we know for a fact that, for example, POV-Ray won't
compile (or otherwise won't work) with certain older versions, we can
include that in the documentation and ideally have the configure script
notice that and whine as well.  You can igore the docs more easily than
the configure script. ;-)
 
> * Could also check the version of the other libraries; should stop when
>    a particular library is not found, with an error message.

Also on todo.  I'm going to need a somewhat broken development environment
to test that. ;-)
 
> * I guess only GNU make will work correctly (untested others make's).

I've heard a bug report that one of the lines in one of the Makefiles is
too long for some make versions.  I'm not sure how far out of my way I'm
willing to go to work around that.  Hopefully there aren't any egregious
GNUisms in the Makefiles, though.
 
> * An option should be provided to customize DISTRIBUTION_MESSAGE_2
> instead
>    of the default "user@machine" replacement.

Agreed, though the default is a good default.  For my own personal use,
I'd be potentially interested in a flag I can use to generate an
"official" blurb.  It's not particulary hard to reverse engineer that
section of the code, so I don't think there's a problem with it being
released to the public, so long as it's not the default.

> * And other things I probably forget or need to be reported first !

Other options I've been meaning to add:

- flags to explicitly not include support for X and/or svga preview

For the case where someone on a machine with X libraries wants to build
a statically linked binary to run on a machine without X libraries.
The workaround currently is static linking.  Workarounds at the code level
are also possible, though I don't expect to do those for 3.5.

-Mark Gordon

Post a reply to this message