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

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


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

Michael Bukin writes:
> Discussion topic: just how crazy is that crazy idea?

Seems a bit unlikely to me, but would be cool if it works.
Maybe a bit over-engineered :-)

But, can't this all be done by the linker?

t.c:

        #include "stdio.h"

        int a;

        extern int b;

        int main()
        {
            a = 42;

            printf("%d\n", b);

            b = 666;

            printf("%d\n", a);

            return 0;
        }

ldscript:

        b = a;

~: gcc t.c -o t ldscript && ./t
42
666

For MSVC, the same thing can be done using dllimport with a cleverly constructed import library (for dynamic linking at least, and I think it would be fair to say that the backward compatibility mode doesn't work with statically linked projects).

It's not really any of my business any more, but I have to say that keeping two copies of the lib around (one prefixed and the other not) seems ugly to me: it's a doubling of the amount of code out there in use and needing to be maintained, and will always be an ongoing task rather than something that can just be solved once and then forgotten about.

My vote would be for a single codebase that implements both old and new API's, and can be compiled for either (but would compile into a different lib depending which is selected, just using the function macros to mangle things differently). That gives 100% compatibility on all platforms without needing any particularly weird tricks, and extends well into the future (people can choose either API, but still be able to access new functionality as it is all the same codebase).

Second to that, a compatibility header for functions with linker fixups for variables seems like a reasonable workaround, although not so robust as the lib actually being rebuilt using either set of names.

If you're going to freeze a version of the old API I reckon it should be just that: freeze it and abandon it, tell people to switch API if they want something that is being actively maintained. Otherwise you will have a nightmare doing support for multiple versions way off into the future. It's a safe bet that 90% of bug reports would never bother to mention what version they were using, and it's hard to always insist people use the most recent if there is such an important reason to go on using and old one! And could be confusing for users if there are multiple 'current' versions on the website, with different reasons to download either. Much simpler IMHO if people can always just download a single latest version, know they will be able to get support only for that, and then just have a configure option to select which API they want to compile it for...


        Shawn.



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