[CF-Devel] crossfire-clients v1.7.0 and arm architecture

Mon Sep 13 01:41:40 CDT 2004

Bob Tanner wrote:
>

      On Tuesday 07 September 2004 03:41 pm, Bob Tanner wrote:

     >

     >>

     Been working with the debian-arm people to try to get crossfire-clients

     >>

     v1.7.0 compiling for the arm processors.

     >

     >

     >

      Status of the gnome client?

     >

     >

      Just remove it from the build system?

  Currently, it doesn't try to build it.  Arguably, there is no reason for make 
to even enter the directory (the gnome makefile right now just says that it is 
disabled, so it doesn't do anything).  I think the only reason that might be the 
case is so when the 'make archive' is done, it packs it up, but since it is 
disabled, probably no reason to include it in official source distributions 
anyways (it is really left there more for historical reasons - no reason to 
actually delete it, as someone could find the code useful)

>

     >

      --enable-ansi is it useful? Do we want to support non-ansi compilers? Any 

     >

      developers -not- using gcc?

  gcc does not equate ansi of course.

  Being able to build without gcc is useful.  However, I think it is safe to say 
that an ansi capable C compiler is required - whether that is gcc or some other 
compiler.

>

     >

      --enable-alsa is it useful? Is anyone running alsa < 0.9.x? I think most 

     >

      everyone should be using --enable-alsa9 -and- should just refactor the code 

     >

      to make alsa9 = alsa.

  Probably not (or at least, no reason to suppor them).  That is more likely 
left over from when alsa 0.9.x was actually still quite new, and a good number 
of people were still using the older version.

>

      So, just dump our platform detection rules in favor of the built-in rules?

  Probably - if those architectures, or others, need specific libraries or 
features, the detection rules should be used instead of the architecture type 
rules (eg, check for appropriate headers, existance of functions, etc)

>

     >

      The whole sound detection code is a mess :-) Went back to  2003-11-25(!) which 

     >

      is alsa-1.0.0pre3, so alsa9 is even pretty ancient.

     >

     >

      alsa

     >

      alsa9

     >

      sgi_sound

     >

      oss_sound

     >

      sun_sound

     >

     >

      How about standardizing on a sound system? SDL has a pretty decent 

     >

      cross-platform system.

  Checking for different versions of the same type of library makes things a 
mess.  It is really the linux platform that causes headaches - do you use OSS or 
alsa?  And which alsa version?

  The sgi/sun stuff should be pretty basic - if you're on those systems, you're 
almost certainly going to use those (although, more fairly, they should probably 
really be called solaris or irix sound system, since linux on sparc/sgi probably 
has the alsa/oss drivers).

  I'd be reluctant to start a redo on the sound playing mechanism until a new 
sound system is sorted out, because in that system, it may be desirable to use 
whatever advanced features of SDL or perhaps other sound system.

  Right now, the sound daemon/helper program itself is pretty basic - I'm a bit 
reluctant to rewrite when it works just fine.  I'd note also that there are 
potentially other requirements that may need to be investigated - I seem to 
recall that gnome or other window managers or the like may grab the sound 
devices for their own use, and there are appropriate APIs or whatnot for an 
application to grab it for its own dedicated use.

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel