Trying to redefine library #defines

My project use a series of libraries, some of which I need to tamper with their preprocessor constants.

PDcurses (a portable curses implementation), for instance, has a some keyboard #defines that I need to alter since not all of them match my system's. Another one is boost::filesystem which uses <errno> for its exception handling. Unfortunately MinGW implementation of errno.h falls short and many of its preprocessor constants don't match my system's error codes.

This is new grounds for me and I'm unsure how I should implement these changes in a portable way.

One possibility I'm thinking is to make my own headers, include these libraries and then use a trio of #ifdef, #undef and #define for those preprocessor constants that I need changed. My app then includes these headers instead of the original ones.

Is this desirable? Not? Or is there a better approach?

There is no portable way of messing with 3rd party libraries, and even less so when messing with system libraries (errno).

But header overriding by placing your own equally named header earlier in the include path is not a bad way of doing it, especially since it means you don't have to modify the current code.

However, there might be problems if through a library-internal include path the unmodified header gets included. Depending on how the compiler looks up include files and how the library includes them, it could happen.

Hmm... maybe perhaps I'm better then defining my own constants and work with them instead of the ones used in these libraries? Instead of trying to redefine those preprocessor constants, I simply ignore them and create my own (with the advantage I can create const constants instead of #define...

You think this possibly a better approach?

If you're creating your own API, then creating your own constants as well seems like a good idea. It's certainly the most maintainable approach.

If you want certain of your constants to directly equate to other library constants, then you're free to make that association inside your code.

Thanks. So it will be.