| RE: [AD] official beta (Re namespace again) |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> > 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
> ?
I mean (1).
> 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
Right. This would be a switch in allegro building, like, say, build the
lib with support for this or that feature. But then, I see a counter
argument there, which I had not thought of:
> This pretty much requires a new name for allegro.h and liballeg.a,
> because people may want both 5.* and 4.0 installed at the same time.
> What about allegro5.h and liball5.a ?
> > 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.
Which is why I only wished :)
> 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.
It kind of bothers me to have this fork, for no reason that compels me.
Having a branch with unprefixed stuff that will have to be maintained
(somehow), without a foreseable end. Merging patches from the HEAD might
prove more and more troublesome as HEAD evolves, becoming a real burden.
> > 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 :-).
Got it, cheers :)