Re: [Alephmodular-devel] Autoconf committed

[Br'fin <br...@ma...>]

On Monday, January 6, 2003, at 07:46  PM, Alexander Strange wrote:

>
> On Monday, January 6, 2003, at 06:36 PM, br...@ma... wrote:
>
>> Alright, I just got Alexander's autoconf patch submitted. Remind me 
>> next time to use a SourceForge tracker page for stuff like that so I 
>> don't spam the list ;)
>>
>> Now, among the files committed as part of this are also 
>> pre-configured versions of the project builder file, the 
>> InfoPlist.strings files and the marathon2.r resource file.
>>
>> So for the time being those files don't strictly need to be 
>> configured.
>
> Except that a 'make distclean' will delete them. (Although, since you 
> need to run configure to get any Makefiles, it's really a moot point, 
> unless we use the automake support for making source tarballs for 
> distribution).
>
>>  But the basics for configuring are in. Though I'd not mind a patch 
>> to flush out the instructions. INSTALL.cvs is correct, if terse. and 
>> by contrast INSTALL seems very verbose :)
>>
>> If you wish to run the autoconf stuff then do the following
>> 	cd alephModular
>> 	sh ./build/unix/autogen.sh
>
> You seem to have changed one instance of 'libtoolize' in that file to 
> 'glibtoolize', and left the other alone.
>
>> 	sh ./configure
>>
>> -Jeremy Parsons
>
> Can I be given CVS commit access? I see several things that could be 
> done (cleanup and optimization in render.cpp, fixing spelling problems 
> in comments, more general autoconf maintenance, etc.) that would 
> produce very large and unwieldy patches to send in.
>

I will give you access for the maintence of the autoconf, Alexander.

I'd have to nix optimization at this point in time. It's not the 
current focus. (And at a time when AM thinks it's drawing 30 frames a 
second, but is getting throttled by the unintentional triple buffering 
of its windows under MacOS X, eeking out more rendering performance 
just doesn't strike me as that important)

I am curious as to what you have in mind for cleanup within render.cpp 
though.

-Jeremy Parsons