Re: [AD] Importing Amiga Allegro

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On 2010-01-30, Arthur Ward <lists@xxxxxxxxxx> wrote:
> Hi Peter.
> 
> Been busy working 12 hour days at work so I haven't had time to get onto
> workin on this unfortunately!  See my responses to your comments below...

Apologies for the delay, forgot all about this.

> > Some minor things:
> >
> > - It would be nice to stick to the standard formatting style, if you
> >   wouldn't mind running an auto-formatter over your code.  If not,
> >   fine.  We're traditionally lenient in the platform-specific
> >   directories, but it *has* left a mess in some directories.
> 
> Yes, I thought long and hard about this.  I always follow coding conventions
> (and have done with any files I've edited in Allegro's src directory) but
> the Amiga's (only) IDE has some serious issues with the Allegro coding
> convention.  So at the risk of making life very difficult for myself I'll
> have to leave the Amiga specific code as it is if you don't mind.  I doubt
> anyone will look at it besides me anyway.  Any contributions to the main
> Allegro source base will follow the conventions of course!

No problem.

> >> +/* Driver info arrays used for by the system driver */
> >> +
> >> +extern _DRIVER_INFO _gfx_driver_list[];
> >> +extern _DRIVER_INFO _digi_driver_list[];
> >> +extern _DRIVER_INFO _midi_driver_list[];
> >> +extern _DRIVER_INFO _keyboard_driver_list[];
> >> +extern _DRIVER_INFO _mouse_driver_list[];
> >> +extern _DRIVER_INFO _joystick_driver_list[];
> >
> > You would be better not to do this.
> 
> Is there any reason for this?  Is it just to keep the number of exported
> symbols down?  I guess I could put each of these into its own .c file with
> a matching function to get the pointer to it.

Just the usual problem that when a symbol is declared multiple times, and the
type needs to be changed, only one of the declarations will be updated.  The
modules which see the old declaration will compile without problems, but could
lead to mysterious behaviour.

These symbols are unlikely to ever change, though, so you could leave it.

> >> +
> >> +unsigned int al_get_sobj_version()
> >> +{
> >> +    return((1 << 16) | 2);
> >> +}
> >
> > Try not to introduce al_* symbols as we are using that for the Allegro
> > 5 branch.
> 
> Bummer.  Changing this now would break compatibility with the 50 already
> released games that use the .so object.  But I'll rename it if ever I
> update the Amiga port to become an A5 port.  Which may happen one day!

Alright.  It's unlikely to clash with anything in A5.

I'm happy for you to check it in!

Peter




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/