Nicolas Calimet wrote:
>> [Thorstens-Computer:~] thorsten% uname -p
>> powerpc
> 
> I guess that's what I need. The configure file itself does
> actually contain most of the things I need concerning platform names.
> What I still cannot guess are the proper compilation flags for most
> platforms.
>
I guess you need a combination. Because:

- Linux ix86: 
uname -m
i686
uname -p: one of 
AMD Athlon(tm) XP processor 1700+
unknown 

- Linux alpha:
uname -m
alpha
uname -p
unknown

- FreeBSD:
uname -p
i386
uname -m
i386

- Sun/Sparc
uname -p
sparc
uname -m
sun4u

Well... maybe you want to have a look at the config.guess of the 
GNU autoconf/automake framework which does all that for you and 
is designed to be portable. 

It's probably a bad idea to try and re-invent the wheel. 

Wolfgang

Post a reply to this message

Thanks for those tips.

> Well... maybe you want to have a look at the config.guess of the 
> GNU autoconf/automake framework which does all that for you and 
> is designed to be portable.

	This is what I'm already doing. This is why I said that the
configure file already contains all the info I need, but I asked
Thorsten to try `uname -m` before I checked in the file itself.
	I need the architecture type to choose the best optimization
flags to use for compilation. Those flags are tested within the
configure script. Actually I should already use those that were
proposed in 3.1g ...

	- NC

Post a reply to this message

> http://www.mersenne.org/

	Okay I'll have a look. Thanks !

Post a reply to this message

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

Mark Gordon <mtg### [at] povrayorg> wrote:
> 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.

  I don't know if this is related, but be aware that using "-static" for
static linking in Solaris causes a linkage error. For some reason the X
libraries in Solaris are not designed for static linking (perhaps they
could be built so that they are, but they aren't here, and I have read
reports of the same issue from other people as well).
  This is a very nasty problem because the error message produced by
the linker is extremely confusing and there's absolutely no hint about
the real cause of the problem (ie the '-static' flag). Finding the cause
of the problem is really difficult if you don't know about it.

  So at least for Solaris the '-static' flag should definitely be turned
off by default.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

On Fri, 21 Feb 2003 05:55:33 +0000, Warp wrote:

>   I don't know if this is related, but be aware that using "-static" for
> static linking in Solaris causes a linkage error. For some reason the X
> libraries in Solaris are not designed for static linking (perhaps they
> could be built so that they are, but they aren't here, and I have read
> reports of the same issue from other people as well).

Oh, yes, I do recall hearing about that.

>   This is a very nasty problem because the error message produced by
> the linker is extremely confusing and there's absolutely no hint about the
> real cause of the problem (ie the '-static' flag). Finding the cause of
> the problem is really difficult if you don't know about it.
> 
>   So at least for Solaris the '-static' flag should definitely be turned
> off by default.

Agreed.

-Mark Gordon

Post a reply to this message

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

	That was meant to be a criticism  :-)

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

	Actually I already contributed several months ago some autoconf
code to test compiler flags, but apparently it didn't catch attention.
Since compiling problems were recurrent (particularly on the odd IRIX
system) I though it was time to contribute a bit more. Sadly I don't
have much time to do more right now...

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

	So here it is. Look at acinclude.m4 for details. This is
some quick adaptation of code I wrote for my own developpments, so
there might be flaws.

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

	Shamelessly borrowed from related libtool's code. Then again
it's not much tested but on Linux and IRIX archs.

> Are you willing to submit bits of this to the official version?

	Sure. Feel free to take anything that suits.

> Your "missing" script is GPL.

	Not only it: config.guess and config.sub are also.
	I know it can be a problem with povlegal, but I'm not going
to rewrite those scripts (or re-invente the wheel, which I actually
do quite often because it's FUN), especially for all those machine-
related tweaks...

>>* Libpng seems to be an issue at least on IRIX
> 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. ;-)

	I guess a test should be straightforward. Since libpng-1.2.3
there is a libpng-config script. IIRC this is at the same time that
-lpng is actually -lpng12. Previous release are all -lpng I guess,
so the only test to do would be to check for libpng-config and
what it returns when present.

> Also on todo.  I'm going to need a somewhat broken development environment
> to test that. ;-)

	I had to install jpeg-6b on my linux box -- initially RedHat 7.2
but augmented a lot by custom installs  :-)  -- and also under IRIX.
So I'll test for this one.

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

	On IRIX it was even worse, since I could basically compile
nothing "descent" like gcc-3.x with the make provided by SGI. As soon
as GNU make was installed, everything became _much_ better (while not
perfect, of course).

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

	I do this directly in autoconf.ac (provided in the tar file).
It's purely sh code. In principle I should create a Makefile target
for that and give a src/optout.h.in, but I was lazy  ;-)

	On the same topic, I wonder whether it's actually required
to create all those Makefile's for scenes/ scripts/ and so on. Have
to investigate it cannot install all without a Makefile in each
sub-directory. But that's not priority.


	BTW, glad to hear about your opinion, Mark  :-)
	- NC

Post a reply to this message

>> Well, Linux is the only system to which I have unfettered access.
>     That was meant to be a criticism  :-)

	Sh.t I should re-read myself before posting...
	Put a "NOT" somewhere in the sentence above, or replace :-) by ;-)

Post a reply to this message

On Fri, 21 Feb 2003 21:43:28 +0100, Nicolas Calimet wrote:

>> Well, Linux is the only system to which I have unfettered access.
> 
> 	That was meant to be a criticism  :-)

I could act indignant here, as though I hadn't yet read the correction
before replying. ;-)

>> Thanks, I'd been hoping for input on this.
> 
> 	Actually I already contributed several months ago some autoconf
> code to test compiler flags, but apparently it didn't catch attention.
> Since compiling problems were recurrent (particularly on the odd IRIX
> system) I though it was time to contribute a bit more. Sadly I don't
> have much time to do more right now...

I recall seeing those.  At the time, it was a higher priority to remove
the hard-coded flags.  I also didn't get around to asking whether you
minded if I used them.

>  >> 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...
> 
> 	So here it is. Look at acinclude.m4 for details. This is
> some quick adaptation of code I wrote for my own developpments, so there
> might be flaws.

Will do.

>>>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.
> 
> 	Shamelessly borrowed from related libtool's code. Then again
> it's not much tested but on Linux and IRIX archs.

Borrowing from libtool is potentially problematic.  In practice, I may be
the only person building statically linked binaries, and it may be just as
well for me to relink manually and let the rest of the world link dynamically.

>> Are you willing to submit bits of this to the official version?
> 
> 	Sure. Feel free to take anything that suits.

Here's where things get tricky.

>> Your "missing" script is GPL.
> 
> 	Not only it: config.guess and config.sub are also. I know it can be a
> 	problem with povlegal, but I'm not going
> to rewrite those scripts (or re-invente the wheel, which I actually do
> quite often because it's FUN), especially for all those machine- related
> tweaks...

Your distributing the script is probably less problematic.  My
redistributing the script as it is might be a problem.  Having to
reimplement a lot of stuff that's under the GPL in order to avoid possible
license hassles is one of the things that's holding back many of the
planned configure script improvements.

>>>* Libpng seems to be an issue at least on IRIX
>> 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. ;-)
> 
> 	I guess a test should be straightforward. Since libpng-1.2.3
> there is a libpng-config script. IIRC this is at the same time that
> -lpng is actually -lpng12. Previous release are all -lpng I guess, so
> the only test to do would be to check for libpng-config and what it
> returns when present.

In case version matters, both the lib and the header have version
information.  Of course libpng-config is more convenient, where it's
present, but lots of people are still using pre-1.2.3 versions.

>> Also on todo.  I'm going to need a somewhat broken development
>> environment to test that. ;-)
> 
> 	I had to install jpeg-6b on my linux box -- initially RedHat 7.2
> but augmented a lot by custom installs  :-)  -- and also under IRIX. So
> I'll test for this one.

I have ways of testing this, don't worry.

>>>* 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.
> 
> 	On IRIX it was even worse, since I could basically compile
> nothing "descent" like gcc-3.x with the make provided by SGI. As soon as
> GNU make was installed, everything became _much_ better (while not
> perfect, of course).

It's probably a high priority for the Makefile for GNU make to be usable
with all sorts of sub-par make implementations.

>>>* 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.
> 
> 	I do this directly in autoconf.ac (provided in the tar file).
> It's purely sh code. In principle I should create a Makefile target for
> that and give a src/optout.h.in, but I was lazy  ;-)

Yeah, I was looking at that.  Problem is, the rest of optout.h can be
updated between releases, so it works best if there's some a very narrow,
highly specific change.  I'd use patch, but I suspect it's not quite as
widely available as sed, which is perfectly sufficient.  For an rpm, I'd
use a patch, since rpm has mechanisms for incorporating patches into
pristine tarballs during the build process.

> 	On the same topic, I wonder whether it's actually required
> to create all those Makefile's for scenes/ scripts/ and so on. Have to
> investigate it cannot install all without a Makefile in each
> sub-directory. But that's not priority.

The scenes directory hierarchy is especially hairy.  I'm using a script to
autogenerate the Makefile.am's out of the source repository, so as to
easily handle addition or removal of scenes.  Making a more flat system
wouldn't really simplify things for the that much at this point.  I'm not
sure it matters so much to anyone else.

-Mark Gordon

Post a reply to this message