Re: [AD] official beta (Re namespace again)

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


Vincent Penquerc'h wrote:
> > If it's in alcompat.c, it means we still need two librares: one with
> > alcompat.c and one without it. I'll assume what Bob said, i.e.:
> 
> Why ? everything in alcompat.c can be defined out by OLD_ALLEGRO_API,
> and thus not defining it would essentially link against an empty file.

Do you mean:
 (1) alcompat.c is in liballeg.a
 (2) alcompat.c is in liballegcompat.a
 (3) the user has to add alcompat.c to his project
?

If (1) or (2), then #defining OLD_ALLEGRO_API in your own source file
has no effect on the library. If (3), then it still requires the person
who compiles to do a change in the installation procedure, which is not
acceptable if non-allegro-programmers shall be able to use source
distributions of programs.

> Ah yes. One wishes for references. We could possibly do something
> about that with those:
> 
> int &allegro_mouse_x = mouse_x;

No, this only works in C++, not C.

> Thinking about it, it need not change the user's code. If Allegro is
> compiled with backward compatibility support, then it can define this
> flag itself, so no change to user code would be needed. Or did I miss
> something ?

Well, if we compile two libraries in any case, then what do we gain over
having them in two separate distributions (4.0 vs. later), as in Peter's
2nd suggestion? This is practically the same as what you propose, except
we don't need any compatibility header.

> I seem to not find this post. Can anyone forward it to me please ?
> I have answers to it, but not Peter's first one, I must have deleted
> it somehow (I only have "[AD] to prefix or not to prefix (sigh)")

OK, I'll forward it (so other people can stop forwarding it now :-).

Sven



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