Hi Przemek, >> I hope Przemek can take an expert look on this issue, >> as I'm sure it's not intentional that such options are >> changing across sources. F.e. this causes unpredictable >> results for anyone using 'harbour *.prg' on a *nix >> system f.e. These pragmas are meant to be per file. > > It was intentional. At least it was strictly necessary in the past > when we haven't full support for .CLP files in Harbour compiler and > additional modules included from .CLP files or by DO command where > compiled just like any other .prg files specified in the command > line so we have to fully replicate Clipper logic in few different > places, i.e. PP should reset newly added user rules but should keep > modifications in standard rules, i.e. if you make > #undef _SET_CONSOLE > in 1-st .prg module then _SET_CONSOLE is not visible also in the > next ones. But if you add: > #define MY_SET > then MY_SET is reset before new module is compiled. > After: > 2009-09-02 14:08 UTC+0200 Przemyslaw Czerpak (druzus/at/priv.onet.pl) > we can exclude from above scenario .prg files passed in command line and > make full compiler reset (in practice it means that we will have to > deallocate nearly everything and allocate and initialize everything from > scratch again) but before you change it please make some tests > with Clipper to not break current behavior for @<name>.clp files and > SET PROCEDURE TO ... / DO ... [ WITH ... ] statements. If you make some > experiments with -D parameter then you will find also some other interesting > things in Clipper. Some of them looks like bugs.
My only concern is #pragmas. Here compatibility doesn't apply as Clipper didn't have them. Do you think it can be fixed to reset the #pragma settings to initial state after compiling each separate source file? Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
