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.
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.
Quote from: oBFusCATed on April 07, 2018, 03:03:19 PM
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.
I forgot to mention my solution include creating a target called "pch" to create the PCH file(s).
Tim S.
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.
Quote from: oBFusCATed on April 08, 2018, 08:58:54 AM
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.
Quote from: oBFusCATed on April 08, 2018, 08:58:54 AM
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.
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.
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...
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.
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.
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
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
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.
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.
Quote from: stahta01 on April 08, 2018, 07:56:11 PM
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.
Created patch to reduce number of files included by PCH
https://sourceforge.net/p/codeblocks/tickets/670/ (https://sourceforge.net/p/codeblocks/tickets/670/)
Tim S.