Re: [Scribia-dev] Throw

[Ludovic N. <lni...@wa...>]

Hello all,

the following email has grown to be quite long and technical as I
scrutinized the problem deeper and deeper. If your interest for proper
project setup is next to NULL, you may be better close it and go earn a few
coins in north pass. On the other hand, if you want to understand the thing
in detail (or if you are Lark, or both ;-) ), this should shed some light.

Ben Hines said:

>However i am having some problems as i do not seem to be getting
>"Throw" dialogs. For example if i forget to register a class in a
>window, i get no dialog - it just fails silently. If i put a
>breakpoint in CScribiaApp.cp at SetDebugThrow_(debugAction_Alert); it
>appears that the macro is dead stripped - cant even break there. It
>is never called. It is as if Debug_Throw were not defined in the
>headers - but it IS defined. Similarly, SignalStringLiteral_() does
>not work at all.
>
>I've spent some time looking through the project settings/code and i
>cant find whats wrong. Can others replicate this, or do i have a bad
>compiler setting?

Well, looked at that a bit. Nasty stuff and honestly very confusing.

In short, there are two compilations paths when you create Scribia

1. Precompiled Headers

The precompiled header mains ource file is DebugPrefix.pch++. This one
includes PrefixCommon.h, which includes PP_DebugMacros.h, which includes
PP_Debug.h, which includes PP_Prefix.h, which includes UException.h, which
includes *tadam* UDebugging.h. And at this point Debug_Throw is not
defined, and thus the Macro compiles to nothing.

But at this point, the precompiled header main osurce file is not finished.
After including PrefixCommon.h, it then includes PP_DebugHeaders.cp. This
file defines the macro Debug_Throw, and this is why if you have the browser
infomation turned on, it appears to be defined. UDebugging.h is later
reincluded from various locations, but it is firewalled with this #ifndef
_H_UDebugging
      #define _H_UDebugging      #pragma once        sequence, which
prevents redefining the macro according to Debug_Throw.

2. the standard source files.
The Scribia projects sets a prefix file for every precompiled source file
using DebugPrefix.h (in C++ language panel). DebugPrefix.h includes the
result of pre-compilation path 1 above. But to make things nastier, it also
redefines Debug_Throw before doing so. Unfortunately., since the
precompiled part is already compiled, that flag has no impact n the
definition of SetDebugThrow_, so you get what you described in your
original question.

Visually, that gives:
DebugPrefix.h
      DebugPrefixHeadersPPC++
        |   DebugPrefix.pch++
        |        PrefixCommon.h
        |               PP_DebugMacros.h
        |                       PP_Debug.h
        |                              PP_Prefix.h
        |                                      UException.h
        |                                             UDebugging.h
        |                                                    #define
SetDebugThrow_ (where Debug_Throw is undefined)
        |         PP_DebugHeaders.cp
        |                   #define Debug_Throw
        |                   #define Debug_Signal
        |                   ... other irrelevant stuff ....

CScribiaApp.cp
       includes DebugPrefix.h as a prefix file
       uses SetDebugThrow_ as defined 5 lines above.
****************************************************
The immediate problem Ben was facing is only related to that. But more
generally, Scribia project is currently weirdly setup, since those 2
compilation paths are not perfectly sequential. The PowerPlant Headers are
compiled in step 1 with some debug symbols set in the TargetPrefix.pch++
file, then the result is later included in a TargetPrefix.h file that also
redefines some of them.

*****************************************************
Now the fix. As soon as we include PP_DebugMacros.h in step 1, we "lose
control" as this is standard PowerPlant code. the comments in PP_Debug.h
mention that the Debug_Throw/Debug_Signal macros must be set prior to this.

Now we can do two kind of fixes: a quick fix, or a clean fix.

The quick fix involves adding those 3 lines in DebugPrefix.pch++, before
the #include of PrefixCommon.h
// Define all debugging symbols
#define Debug_Throw
#define Debug_Signal

// Bring in common settings
#include "PrefixCommon.h"


The clean fix requires understanding one of the role of PP_DebugHeaders.cp.
This file is there to provide default behavior for Debug targets. But since
we override some of those defaults, namely
#define PP_StdDialogs_Option	PP_StdDialogs_Conditional
#define PP_Uses_Old_Integer_Types 0
we *should* stop using PP_DebugHeaders.cp in our include file, but rather
use our own including there.

So the proper way of fixing that stuff:
a) add those two lines at the end of PrefixCommon.h, since this *is* common
to all targets.
// Bring in PP headers.
#include <PP_ClassHeaders.cp>
b) remove #include <PP_ClassHeaders.cp> from FinalPrefix.pch++
     remove #include <PP_DebugHeaders.cp> drom DebugPrefix.pch++
c) add #include "DebugPrefix.h" at the very top of DebugPrefix.pch++
     add #include "FinalPrefix.h" at the very top of FinalPrefix.pch++
d) remove the #include of the binary precompiled haeders at the end of both
      DebugPrefix.h and FinalPrefix.h
e) move the #define	PP_MoreFiles_Support	1	// OFF by default
 from DebugPrefix.h to PrefixCommon.h, before the #include <PP_DebugMacros.h>
(Please note that PP_DebugMAcros.h is not a Debug-specific file, it must be
included in every target as it defines non-debug versions of debug  macro
utilities to nothing or their no-overhead production equivalent).
f) change the Prefix file in the C++ language panel to be the binary
DebugPrefixHeadersPPC++ and equivalent non-debug (and 68K if any) binaries
for other targets

Why doing all this?
-make sure things are not defined multiple times in multiple places
-ensure we are really using the debug headers to *only* define debug
related elements (and not MoreFiles support, for example
-having the proper debug symbols at all steps of the precompilation and
compialtion process when compiling a debug target (so that Ben can stop at
that macro ;-) )

I know it may seem a large set of changes for little appearant gain.
However, I think they are good on the long term as we grow using more debug
capabilities, and start having other people concentrating on little parts
of the code only and wanting to have a general environment well setup.

Also, maybe some people don't like the idea of setting the binary
precompield header as such in the project settings. if so, we can actually
create a.h file that would include them. But IMHO, this is just adding more
indirection and confusion with no gain. if you have valid reasons to reject
that approach, please let me know.

I just compiled a newer version of my own Scribia version with those
modifications, everything is fine and same as before, aside the fact those
macros have a break line available now.

Geotzou, now let's log a third ticket onto SOurceforge so i could do all
this myself.