The African Chief wrote:

No. SYSTEM.INC (which is $INCLUDEd into GPCTYPES.PAS) contains this;

{.$DEFINE _Borland_16_Bit_} { 16-bit Borland data types } {$DEFINE _Borland_Pascal_} { Borland string types }

Ah, now I understand! Looks reasonable to me.

Yes, it is giving me problems with certain things in the cygwin32 C headers. It would have made things a lot easier if they could be exported in units - but you can't have everything ! ;-)

Why not? This is gpc! ;-)

...

The only way to do it (AFAICS) are include files, or defines on the command line. (BTW: does "-Drandom=RandReal" or such work, or could it be made to work?)

I am not sure.

I just tested it, it seems to work already!

That would make my life a lot easier with translating C macros to Pascal. However, it may be of dubious long-term benefif. At the moment, I have to translate all those C macros into Pascal functions. This is bit tedious, but it is probably better in the long run. Who knows?

I think it's better to translate them to functions wherever possible, though it is tedious. But there may be some things left that can't be translated adequateley -- overloaded functions are one such thing (perhaps some day they will be possible in gpc, too), and there may be other things...

On a somewhat similar but different topic:

Perhaps the state of some compiler switches that influence the generated code (e.g. range and stack checks when they're implemented; probably not optimization) and all the defines that are active at the beginning aof the compilation of a unit could be stored in the .gpi file. When the unit is used, and automake is active, the compiler could check if the current settings match those stored in the .gpi file, and if not, have the unit recompiled. So, if one wants to change one switch (e.g. the _Borland_16_Bit_ above), one could still use the automake and have all units updated if necessary. (In the case of defines, this would also require to store in the .gpi file which defines are tested or used, so that changing an unrelated define will not cause to unit to be recompiled.)

And how about something like "--autobuild" to compile all units whether or not this seems necessary? This could be useful for a final compilation of a project (probably with a highest optimization), or to recompile something for a different platform in the same directory without having to manually remove all the .{o,gp[mi]} files (this happens to me often with DJGPP and Linux).