Adding Precompiled Headers to vs-android – Part 2

Following on Adding Precompiled Headers to vs-android

No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength – Helmuth von Moltke the Elder

With my PCH-support hammer in hand, I went to find anything I could that uses a PCH. With this further testing I managed to uncover a few more issues that really need to be resolved before support for PCHs could be considered for adding to vs-android.

Missing Directory Fail

The first thing I found was that if the PCH output directory (remember that we put all the different PCH outputs in one directory for GCC to check) was missing, the build would fail at the PCH creation stage. To handle this, we need to add a new MSBuild target before the ClCompile target that performs the PCH and C/C++ compilation. For this target we need to make a list of all of the possible output directory names for PCH files and then invoke the Makedir task to create the directories. In MSBuild language, you need to add this to the Microsoft.Cpp.Android.targets* file:

<Target Name="CreatePCHDirs"
     <GchDirsToMake Include="%(ClCompile.Identity).gch\" Condition="'%(ClCompile.CompileAs)' == 'CompileAsCHeader' or '%(ClCompile.CompileAs)' == 'CompileAsCppHeader'"/>
   <Makedir Directories="@(GchDirsToMake->DirectoryName()->Distinct())" />

Gotta Link ’em All

One other issue I found after applying PCH support to all the libraries I could find, when I updated an application to build with a PCH. This then failed to build when the linker thought it should helpfully link in the PCH output, and then fail. Looking at the log, I found there’s a LinkCompiled property of ClCompile elements which we could clear to tell the linker we don’t want it. To do this, go back to the Microsoft.Cpp.Android.targets* file, and after the  ObjectFileName override from last time, add the following in the same group of elements:

 <LinkCompiled Condition="'%(ClCompile.CompileAs)' == 'CompileAsCHeader' or '%(ClCompile.CompileAs)' == 'CompileAsCppHeader'">false</LinkCompiled>

Are we done yet?

Hopefully so. I’m much happier with this and it now works with everything that I could apply it to.

*Note again that there’s 2 copies of each file once vs-android has been deployed – one under C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Android\ (for VS 2010) and the other under C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\Android\ (for VS 2012). You can make these changes prior to deployment, but that’s harder to test.


2 responses to “Adding Precompiled Headers to vs-android – Part 2

  1. Pingback: Adding Precompiled Headers to vs-android | dickyjim

  2. Hey Richard,

    Starting to integrate your change this evening. Noticed the comment about copying the files. I use this batchfile to push over changes:

    attrib -r /s /d "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Android\*.*"
    xcopy "D:\Projects\vs-android\trunk\MSBuild\Android\*.*" "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Android" /s /y
    xcopy "D:\Projects\vs-android\trunk\MSBuild\2010 DLL\*.dll" "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Android" /s /y
    attrib +r /s /d "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Android\*.*"
    attrib -r /s /d "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\Android\*.*"
    xcopy "D:\Projects\vs-android\trunk\MSBuild\Android\*.*" "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\Android" /s /y
    xcopy "D:\Projects\vs-android\trunk\MSBuild\2012 DLL\*.dll" "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\Android" /s /y
    attrib +r /s /d "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\Android\*.*"

    Replace “D:\Projects\vs-android\trunk” with your own dev directory. I like setting the read-only flags back under \Program Files\, so I don’t accidentally make edits to them.

    Changes to the .props/targets generally reflect fine in VS without a restart of it. Changes to property .xml files don’t. You need to restart there.

    When building DLLs you can’t replace them if there’s a running MSBuild.exe process, from a previous Android build. You have to kill off the process, even a close/open of VS isn’t enough. I should probably find a cmdline tool to do it for me, I end up just using TaskMan. 😦

    I’m most of this isn’t news to you, but figured I’d share if it’s useful.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s