[OpenWalnut-Dev] new branch for PCH and unity builds

[Alexander Wiebel]

Hi,
for everyone who did not get it:
Everything he describes can be found in the "Ledig" branch only. It will be 
moved to the default branch only after a positive discussion on this list.

Best,
Alex

> Hey all,
> 
> I think you all recognized by now that OW got pretty huge and takes a
> lot of time to build.
> That in mind and reducing that cost I implemented 2 features in cmake
> I'd like to explain further.
> 
> Unity-Build:
> instead of building every cpp on its own and linking them together
> afterwards,
> this build method creates one new cpp file for each target.
> Every other cpp is getting excluded from the build.
> The new cpp file contains only includes to all the other cpp files in
> the target.
> Might sound not that a good idea but it has some nice effects:
> - for me build time for some targets reduced from more then 6 minutes
> down to less then 1
> - the compiler can optimize more because he has more context information
> of what he should produce resulting in lower binary size
> Downside of Unity-Build:
> - a change in any of the targets dependencies will result in a complete
> rebuild of the target
> 
> Precompiled Headers(PCH):
> this one is complicated.
> It keeps all the cpp compile order but instead try's to minimize the
> compile time for each of them.
> This is achieved by creating a precompiled header, which is just a new
> cpp and h file creating another linkable object.
> The cpp only contains the include of the header.
> The header has all the (hopefully) never changing headers, used by the
> target.
> This should result in a low ratio of rebuilds for the PCH because its
> expansive to build.
> In order to make it work in a build a few compiler flags have to get set
> and every cpp of the target needs to include the pch as the first of its
> includes.
> To make this work a wrote a little python script, which scans all the
> files in a target for includes, compares them to files inside the target
> and, if not contained in the target, writes them with there include
> guards to the PCH.
> Additionally the script adds the pch include as the first include in
> each of those cpp's. (right after the OW copyright block)
> I noticed that might infect the commit because the cpp's including a PCH
> will be marked as changed and someone pulling this will get compile errors.
> So the cmake/python combo also removes the changes and files in makes if
> unchecking the PCH support.
> 
> Both methods can be turned on with cmake but are off by default.
> They can and should not be combined, in fact I turned of PCH building if
> unity build is turned on so it wont conflict in cmake.
> Also for PCH to work i had to rename the targets because gcc behaves odd
> with the -DOWtargetName_Exports flag.
> To get there i unified the CMake files to use variables instead of
> constants for targets which has only effect if PCH is turned with gcc
> and otherwise makes it more comfortable to rename targets and module
> prefixes.
> While i'm at modules, in order to make PCH or UB usefull for them, both
> methods only get active in a module if it contains at least 3 cpp files.
> 
> I couldn't test PCH build with gcc extensivly but I think it's not
> appropriate there.
> I'd like to have some feedback on this, does it help in any way to the
> compile speed and if so how.
> My expirience is that my build in VC went from above twenty minutes to
> around 4-5 (without tests and complete rebuild)
> A concrete example is the OWcommon:
> normal rebuild: 6:40 min (dual core parallel build)
> PCH rebuild 1:20 min (dual core parallel build)
> UB rebuild 0:42 min (only one core got used)
> 
> So far, i'm eager to get feedback,
> greatz Robin
> _______________________________________________
> OpenWalnut-Dev mailing list
> OpenWalnut-Dev at lists.informatik.uni-leipzig.de
> http://lists.informatik.uni-leipzig.de/mailman/listinfo/openwalnut-dev