RFC: On PCH simplication under Windows

[stahta01]

Currently, the building of sdk.h as a Precompiled Header (PCH) requires these defines in the Windows CB Project
__WXMSW__
WXUSINGDLL
wxUSE_UNICODE
CB_PRECOMP
BUILDING_PLUGIN
cbDEBUG
HAVE_W32API_H

I wish to know if patches would likely be accepted to reduce it to these defines?
__WXMSW__
WXUSINGDLL
wxUSE_UNICODE
CB_PRECOMP

Tim S.

 

[oBFusCATed]

Can you explain why these defines are required?
Generally I don't like the whole precompiled stuff.
Every time I change a major header everything is recompiled, so annoying...

I would happily remove the pch and rework the headers to be less dependent.

[stahta01]

Can you explain why these defines are required?
Generally I don't like the whole precompiled stuff.
Every time I change a major header everything is recompiled, so annoying...

I would happily remove the pch and rework the headers to be less dependent.

From experimentation I think these two rules apply to defines and PCH file usage.
1. If an define is declared while compiling the PCH; then, it must be define while using the PCH.
2. If an [new] define is declared while using the PCH that effects the headers include by the PCH then it will not use the PCH.

The plan to fix the problem is to remove the code effected by defining cbDEBUG and BUILDING_PLUGIN [from the PCH file].
And, just to not define HAVE_W32API_H inside the windows projects. The wxWidgets 3.0 define it in code and it should not cause issues.
Note: It might cause issues in wxWidgets 2.8; did not check it out much in it.

cbDEBUG effects cbexception.h
 The plan is to split part of the code in cbexception.h into a new header cbassert.h
BUILDING_PLUGIN effects cbplugin.h
 The plan is to remove cbplugin.h from sdk_common.h

Both of those two patches will include a lot of files being changed.
The first one I have done a first attempt and I am sure it is likely possible to do.
Just have one small part of the patch that an C++ expert needs to confirm is correct.

The second patch will take a while to create to confirm the idea is valid.

Tim S.

[stahta01]

I forgot to mention my solution include creating a target called "pch" to create the PCH file(s).

Tim S.

[oBFusCATed]

Why another target? The two files have correct weights...
Do you see any difference in compile times with your changes?
Because if there is not difference I don't see why we should bother at all.

[stahta01]

Why another target? The two files have correct weights...
Do you see any difference in compile times with your changes?
Because if there is not difference I don't see why we should bother at all.

After adding the path to the PCH; my times are cut by 30 to 50 percent for the contrib projects.
But, that is without my patches.

My patches are to make it easier to use the PCH file (sdk.h) in the contrib projects.
Since, every time I have posted my patches to fix the PCH in the contrib projects I have been ignored I gave up on posting that fix and
decided the ease of use might be the problem.

Tim S.

[stahta01]

Why another target? The two files have correct weights...

The pch target is planned to reduce the number of the defines to the minimum needed.

Tim S.
 

[stahta01]

I am looking at the SDK headers you edited in the last 3 months; and, it looks like removing several of those headers make sense from the sdk PCH file.

I will see which CB SDL files in sdk_common.h are good candidates to remove from it.

If the number of files in sdk_common.h are reduced it will not need to be compile as often and will compile faster.

This could take a while to figure out which files should be kept and which should be removed.

It might take me a few weeks just to decide the best way to judge the best way to proceed.

I will likely need to find out how to get reports from git on the header files most often edited.

Tim S.

[oBFusCATed]

Why do you care about how often a header is edited?
The important metric is how often it is included without being needed.
I often edit random headers and if I could I would disable the pch, but currently this is not possible.
The compilation is fast (around a minute for all the core targets), so it doesn't bother me too much, so I don't do anything about this problem.
Also the idea of the pch is to help with compilation speed. So you should measure the effect of every header included in the pch on the compilation speed...

Generally I have the idea to do a cmake based build system, because editing 5-6 sets of cbp files is quite annoying and it is not possible to create a command line build on windows. So I cannot setup an appveyor builds similarly to the travis builds...

But I don't have the time right now...

[stahta01]

Because one of the things that is suggested is NOT to put headers into a PCH that is frequently edited.
The other criteria is to put headers that are included by many source files into the PCH.

Based on the last 3 months cbplugin.h almost counts as frequently edited.

Another rule is to avoid putting headers into the PCH that breaks the PCH build.
There is 3 or 4 files that breaks the PCH build; found out by adding them a few years ago.

The results of a quick manual search using an GUI search tool.

Tim S.

Code

settings.h            found in  65 cpp files and in 56 sdk header files
globals.h             found in 180 cpp files and in 19 sdk header files
sdk_events.h          found in  38 cpp files and in  1 sdk header files
cbexception.h         found in  35 cpp files and in  6 sdk header files
logger.h              found in  16 cpp files and in  3 sdk header files
editorbase.h          found in  13 cpp files and in  1 sdk header files
cbeditor.h            found in  93 cpp files and in  1 sdk header files
compileoptionsbase.h  found in   3 cpp files and in  2 sdk header files
compiletargetbase.h   found in   2 cpp files and in  4 sdk header files
projectbuildtarget.h  found in  22 cpp files and in  1 sdk header files
projectfile.h         found in  13 cpp files and in  1 sdk header files
cbplugin.h            found in  26 cpp files and in  4 sdk header files
cbproject.h           found in  99 cpp files and in  1 sdk header files
cbtool.h              found in   3 cpp files and in  1 sdk header files
cbworkspace.h         found in  15 cpp files and in  0 sdk header files
compilerfactory.h     found in  36 cpp files and in  1 sdk header files
compiler.h            found in  30 cpp files and in  1 sdk header files
workspaceloader.h     found in   9 cpp files and in  0 sdk header files
editorcolourset.h     found in  32 cpp files and in  0 sdk header files
pipedprocess.h        found in   4 cpp files and in  0 sdk header files
scrollingdialog.h     found in  13 cpp files and in 24 sdk header files
cbauibook.h           found in  24 cpp files and in  1 sdk header files
manager.h             found in 215 cpp files and in 19 sdk header files
configmanager.h       found in 200 cpp files and in  3 sdk header files
editormanager.h       found in 116 cpp files and in  1 sdk header files
logmanager.h          found in 169 cpp files and in  1 sdk header files
projectmanager.h      found in  87 cpp files and in  2 sdk header files
menuitemsmanager.h    found in   3 cpp files and in  2 sdk header files
scriptingmanager.h    found in  16 cpp files and in  1 sdk header files
toolsmanager.h        found in   5 cpp files and in  0 sdk header files
templatemanager.h     found in   5 cpp files and in  0 sdk header files
macrosmanager.h       found in  46 cpp files and in  1 sdk header files
pluginmanager.h       found in  30 cpp files and in  3 sdk header files
personalitymanager.h  found in  15 cpp files and in  0 sdk header files
uservarmanager.h      found in   7 cpp files and in  1 sdk header files
filemanager.h         found in  14 cpp files and in  1 sdk header files
xtra_res.h            found in   6 cpp files and in  0 sdk header files
safedelete.h          found in   2 cpp files and in  1 sdk header files
infowindow.h          found in  21 cpp files and in  0 sdk header files
licenses.h            found in   1 cpp files and in  0 sdk header files

Looking at selected files; I am currently thinking to follow the Keep and remove below under Linux
(It gets more consistent build times).
And, then try removing things not in the keep list and see if the core project build time drops.

Code

Keep in PCH
  settings.h
  globals.h
  manager.h
  sdk_events.h
  cbexception.h
  configmanager.h
  editormanager.h
  logmanager.h
  logger.h
  projectmanager.h
  macrosmanager.h
  cbproject.h

Code

Remove from PCH file
  licenses.h
  safedelete.h
  xtra_res.h
  filemanager.h
  uservarmanager.h
  templatemanager.h
  toolsmanager.h
  pipedprocess.h
  workspaceloader.h
  cbtool.h
  cbauibook.h
  scriptingmanager.h
  pluginmanager.h
  editorcolourset.h
  personalitymanager.h

 

[stahta01]

I am also trying to remove files that include "wx/wxscintilla.h" because it should make it easier to update the wxscintilla code.
And, it makes it easier for people to use the PCH file for non editor plugins.

That is why I am planning on removing "editorcolourset.h" from the PCH file.

Tim S.

[stahta01]

Looks like C::B does not work enough better with a separate target called "pch" to be worth doing it.
So, once I finish testing will move the PCH file back to normal target.

Tim S.

[stahta01]

Looks like C::B does not work enough better with a separate target called "pch" to be worth doing it.
So, once I finish testing will move the PCH file back to normal target.

Tim S.

I am having second thoughts about adding an pch target in Windows projects.
The gain might be worth it; but, just under Windows.


But, I have decided to do the "PCH simplication under Windows"; After, I reduce the number of headers included by the sdk.h PCH file.

I am now testing the Linux patch file under Windows to see what needs fixed in the Windows only plugin(s).

Tim S.

[stahta01]

Created patch to reduce number of files included by PCH
https://sourceforge.net/p/codeblocks/tickets/670/

Tim S.