[crossfire] broken configure on opensolaris

[AnMaster]

On 2010-10-13 08:00, Mark Wedel wrote:
> On 10/12/10 10:09 AM, James Lopeman wrote:
>> This issue is the second time auto-junk has broken on invidious (up to date
>> centos 5.x ). Its a common OS on rented colo/virtual servers.
>>
>> As an example centos uses libtool 1.5.22 ( June 2007 ). This is what invidious
>> is using right now. I fixed mine with a new automake (1.11.1) and
>> autoconf(2.6.3).
>>
>> I'm not sure how a developer is supposed to know what versions of things are
>> on all long release server OS's are, or what combo's are needed to work.
> 
>   Yes - that is really the problem.
> 
>   But I can also see where it is hard from a developer making these changes - he 
> probably has recent versions of those utilities, and the changes made worked on 
> that system, so it is hard to know what the minimum needs really are.
I do indeed have recent versions of these tools, but it is more confusing that
it broke at all. The test seemed pretty straight forward and I didn't find
anything indicating that I used some unsupported feature, I based the new file
on the python checking code we already had for this very purpose.

I did not commit the updated aclocal.m4 for this very reason. Since it showed
that lots of libtool code had changed. I don't have easy access to old
versions of the tools. Installing those system wide would probably be quite
tricky without completely breaking the system. Installing autotools/libtool
stuff outside standard paths never worked for me before (the tools seemed to
prefer calling the distro-installed ones anyway, even though the locally
installed ones were first in $PATH).

>   In some cases, the documentation may state that information.  The GTK 
> documentation states pretty clearly when a particular function was added, so if 
> you are using that, you can know the minimum version of GTK that is needed.
> 
>   I don't know if the auto tools and like do that.  But even if they do, it 
> could be tricky - you might see some configure file for some other project and 
> say 'that is a good way of doing it' and copy/paste it - it is unlikely you are 
> going to check the docs to see minimum revisions that are needed for those features.
Very rarely does autotools documentation state when something was added.
> 
> At one point, a decision was made not to include files that are automatically 
> generated (makefiles, configure, etc) in SVN.  That is a decision that is still 
> the right one IMO, but does mean that these types of issues show up.
Then aclocal.m4, autoconf.h.in and a few more files should go away since they
are auto-generated.
> 
> I'm just not sure what a good solution is - but what we currently have right now 
> doesn't seem that great.

/Arvid Norlander