So continuing on from my idea - it's mostly bollocks. There's no easy way to partially parse through a header file and record the switches so that we can quickly assemble a valid C Interface class at runtime based on a bunch of switches.

So, dumping that idea, we can go back to just making a regular c pre-processor right? Perhaps. We could run the pre-processor through like normal, then get all the definitions in a Class, eg: LibXYZ, then make subclasses of that class such as LibXYZ_win32_x86_gcc which define the methods valid for that configuration.

That's not too difficult to do and would work pretty well. So, if that's all we need to do - then we just need to make a c pre-processor in Smalltalk.

Hey, if we're just doing that - why don't we just use the platform's c pre-processor program, such as cpp on Linux, etc.

Okay, so the reason we cannot do that is more to do with the way C compilers work than with Smalltalk. When you go to include some libraries header file, eg: libxyz.h - it may have includes of its own to suck in definitions from the system, such as from stdio or stdlib, etc. It may do this to re-use the type definitions from that header file. This makes perfect sense - and in a regular c pre-processor it will literally inline those other header files switched based on the define's that we've already got running.

Then the C program uses those various definitions and eventually you actually link up to the libraries. In essence, the header files and the libraries are completely separated in the C compilation process. There's dependency between them. If any one else wants to interface with C, we really cannot do that, we need to link a library up to its header definitions - otherwise the world simply doesn't make sense.

So, if we're doing that and we use a platform c pre-processor, that means that our libxyz's C Interface class will include all of the definitions from, say, stdlib which of course links up to libc.so etc. This would not be very good - and naturally it is also completely wrong.

So, we want to treat includes a little differently. We want to know that we're doing an include and we want to be able to reuse the definitions from the include, but at the same time we don't want to actually -include- those definitions in to our resultant C Interface class. Following still?

This leaves us with a new conundrum. What if the include'd header file has a define that uses a variable that wasn't defined the first time we ran it - but is now that we're running it as an include. It means we want to reuse some information from the include that wasn't recorded, yet at the same time we don't want to say that information comes from our header file. Ooh, nasty stuff.

Well, my brain is still ticking over on this. I'm sure the answer is simple and requires as little work as possible. So, are there any other reasons to not use a platform c pre-processor? Well yeah, first of all that means you have an external dependency to Smalltalk on each platform just to parse some header files. This is probably a reasonable dependency, but any dependency we can avoid the better.

And let's not forget that we can then re-use the technology for other cool and advanced things (more on those later I guess). And let's not forget we may want to use those define's for our own neferous purposes too ;) - such as making a pre-processor run on smalltalk code when you save it.

I had someone ask me to think about the "arms race" - ie: non-standard extensions to the pre-processor protocols and rules and pragmas etc. Luckily, this seems to have basically stopped. Virtually no one is making a new C compiler any more - and even if they are, they're generally not putting any new effort in to the pre-processor. The last thing I remember being added to the c pre-processor environment was the __in and __out stuff that Microsoft came up with. They did that entire thing using macros any way - so it's not even an abuse of the pre-processor rules.

Personally, I'm not too concerned about the arms race going crazy again. The modern c pre-processor was defined in 1999 for the C99 standard. DLLCC was written before that, so it's no wonder things don't work the way they should now. I guess time will tell.

For now, I just need to puzzle over these last few issues - and then may be we can try something out as a prototype and see what kind of result we get.