Precompiled Headers

Developers
John Emmas
2005-09-27
2013-04-29
  • John Emmas
    John Emmas
    2005-09-27

    Sometime since my last full build (I can't be sure exactly when) my Debug version of Impl.pch became corrupted. My first thought was to delete it and rebuild - but no matter how I tried to recreate the PCH file, I would always end up with linker errors when building the COMAPI branch (mostly about undefined or multiply defined symbols). I eventually managed to solve the problem by restoring an old backup but this set me wondering....

    A) Is there a "recommended" way for rebuilding the project's precompiled headers if they become lost or damaged?

    B) Why won't the AAF library code build if precompiled headers are turned off?

    Any advice would be most welcome.

     
    • Tim Bingham
      Tim Bingham
      2005-09-27

      Precompiled headers are fine if you want the wrong answer quickly - I'd prefer to wait and be sure of the right answer.

      I'd suggest that we turn them off.

      We've done so here at Avid. When I turned them off I found that the thing didn't build. One cause was #includes missing from the source code but supplied by precompiled headers and/or forced includes in the projects.

      FWIW here are my notes that I sent to Avid developers -

      Hi,

      I've made many changes to the AAF .vcproj files (MS VS/C++ v7 aka .NET). You should find the projects cleaner, with many fewer warnings and you should run into no more dependency problems.

      The changes are -

      Disable precompiled headers
      Remove stdafx.{cpp|h} files from projects
      Remove "forced includes" from projects - fix resulting compilation errors (we were referring to symbols defined in files included by the project rather than by the source code)
      Remove output files (e.g. .bsc) that had been added to projects
      Implement the clean target for MakeSDK - fix resulting build errors (projects that should have depended on MakeSDK did not, these may have failed to build the first time around, and probably used stale libraries and headers on subsequent builds)
      Get rid of linker warnings about unsupported "DESCRIPTION" directive in the .def files.
      Get rid of linker warnings about /INCREMENTAL:NO and /EDITANDCONTINUE (by enabling incremental linking)

      The builds are now warning free except for 3 warnings in the release build of the form "LINK : warning LNK4089: all references to 'ole32.dll' discarded by /OPT:REF"

      Let me know if you encounter any problems that may be caused by these changes.

      Cheers,
      Tim.