(This is also logged as ID# :3027562)

   I sure wish I'd had a chance time to test PFE earlier... 
unfortunately it always seems that Apple's release cycle coincides with 
a major crunch time around here for me :(

   Anyway, some of Omni's source exhibits a wide variety of PFE bugs.  
I've made smaller test cases for some of these bugs and reported them, 
but some of them are hard to reproduce in small test cases.

   I've placed two packages on our web site that will help demonstrate 
these bugs:

http://www.omnigroup.com/~bungi/OmniBase-PFE-20020819.zip
http://www.omnigroup.com/~bungi/OmniFoundation-PFE-20020819.zip

- Make sure you have PB set to have a separate build products directory
- Build OmniBase (it doesn't use PFE at all yet) -- it's just needed 
for OmniFoundation
- Build OmniFoundation (which is configured to use PFE).


   The problems you will notice, not necessarily in the right order, 
though (along with the workaround you'll need to employ to get to the 
next problem):

- In OFWeakRetainConcreteImplementation.h, there is a static inline 
function _OFWeakRetainRelease.  This is used by various files, notably 
OFScheduler.m (which I've put first in the target for your 
convenience).  This inline causes the compiler to crash when loaded 
from a PFE.  Commenting out various portions can make the crash go 
away, but I've not been able to reproduce this problem in a simpler 
test case.
        Wordaround: For now, you can just #if 0 the entire contents of the 
function.  This function is really too big to be an inline anyway and 
should just be extern.  Still, it should work either way.

- The DEFINE_NSSTRING macro from OmniBase doesn't work.  It works fine 
w/o PFE, but PFE breaks the preprocessor concatenation.  Clearly we can 
just avoid using this macro and define our string constants by hand.  
Still should work, though.
        Workaround: Rewrite the few DEFINE_NSTRING macros to 'NSString *Foo = 
@"Foo"'

- Even though 'PFE_FILE_C_DIALECTS = objective-c' in the Expert View 
for the main target, md5c.c and sha1.c will fail to build.  Renaming 
them to .m files avoids this problem, but this is clearly non-optimal 
in large projects.  We could also maybe add '#ifdef __OBJC__' wrappers 
in our pch.h so that the PFE for C could be built.  This would still be 
non-optimal though since there aren't enough C files to really justify 
building a PFE for them.
        Workaround: Rename the files

- Mysteriously after fixing all these problems, there will be an 
unresolved symbol.   The symbol is a static inline and so shouldn't be 
missing.
        Workaround:  Dunno.



-tim

Reply via email to