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