sakra / cotire Goto Github PK

I often use Qt, and its newer versions (4.x with CMake 3, and 5.1.1+) apply a compile definition QT_NO_DEBUG conditionally, through a generator expression assigned to an imported target property.

Unfortunately, cotire writes its script file before that property value is resolved, and the prefix header is compiled with the definition still looking as $<...>. Therefore it can't be used in the compilation of the source files.

The only solution I can think of is file(GENERATE ...) command, but:
a) it is only available in CMake 2.8.12+;
b) it requires a unique output file for each invocation and for each build configuration.

So we have a bunch of compiler warnings enabled (as errors), and disable them on system includes using -Wno-system. We use -isystem to include these headers (e.g. boost) using clang. After enabling cotire, we are getting compiler errors for these headers. It seems the #pragma clang system_header pragma in the precompiled headers isn't taking effect correctly. I'll try to create a sample project when I have time, but I want to get this in here now in case others are having this issue and can help.

If I do not enable cotire for my large-ish project, cmake 3.1.3 takes about 1 minute to configure it.

If I enable cotire (1.6.9) configure time is 45 minutes. Obviously, the compile time improvements I get are totally negated by the excessive configure time.

This seems to be a regression, it didn't used to be like this, i.e. in the past the two configure times were the same.

This is on Windows 7, 8, and 8.1, with cmake 3.1 to 3.1.3 (dont know about newer, cannot check older).

What would be the best way to figure out what is going on?

Following the instructions in the manual, I've tried to setup a simple project using a designated precomputed header with something along the lines of:

cmake_minimum_required(VERSION 2.8.0)
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake")

project(CotireTest)

include(cotire)

add_executable(hello_cotire precompiled.cpp main.cpp precompiled.h)

set_target_properties(hello_cotire PROPERTIES COTIRE_ADD_UNITY_BUILD FALSE)
set_target_properties(hello_cotire PROPERTIES COTIRE_ENABLE_PRECOMPILED_HEADER TRUE)
set_target_properties(hello_cotire PROPERTIES COTIRE_CXX_PREFIX_HEADER_INIT "precompiled.h")

cotire(hello_cotire)

get_target_property(_prefix hello_cotire COTIRE_CXX_PREFIX_HEADER)
get_target_property(_precompiled hello_cotire COTIRE_CXX_PRECOMPILED_HEADER)

message("prefix " ${_prefix})
message("precompiled " ${_precompiled})

You can find the entire project here:
http://github.com/zah/hello_cotire

If I enable COTIRE_DEBUG and COTIRE_VERBOSE, I get this:
https://gist.github.com/zah/5598251

In the generated project files, none of the sources have the "Use Precompiled Headers" option enabled. The property COTIRE_CXX_PRECOMPILED_HEADER doesn't seem to be set to anything as shown in the log.

My cmake version is 2.8.10.2
I've tried to generate projects for Visual Studio 2012 and Visual Studio 2008.

at cotire.cmake:526

_compileFlags should be _compilerFlags

if (COTIRE_DEBUG AND _compileFlags)
    message (STATUS "Target ${_target} compiler flags ${_compileFlags}")
endif()

During the setup of a new project i noticed that if a project has a single "main.cpp" file (more to be added in the future) and COTIRE_MINIMUM_NUMBER_OF_TARGET_SOURCES set to 0 then the generated visual studio project gets 2 files instead of one:

main.cpp
NewProject_CXX_unity.cxx

I know it doesn't makes much sense to unity build something that doesn't really need it performance wise but it does help setup up the project environment and assuring that all dependencies work fine together.

Hi, for now cotire auto generator the PCH headers.
But I want specify the PCH header file, e.g. StdAfx.h or pch.h.
I thought this is the missing feature.
Could you impl it? Thanks!

Hey Sascha, we are about to start using your cotire in our company.
Is that possible that you tag your releases instead of adding a comment of your git commits? Use the comment to describe the changes

to add a annotated tag in git just

git tag -a -m "a comment" TAGNAME
git tag -a -m "a comment" cotire-1.6.0

you can also tag prevouis version specifying the commit at the end i.e.

git tag -a -m "my comment" cotire-1.5.1 845e0a4

Thank you so much for you work
Looking forward using it to speed up our builds
Fede

I just learned about cotire and was very impressed. Just what I always wanted! PCH in a box!

So I just tried and applied it to a project on VC11 that is rather heavy on templates boost and spirit and such and it almost worked, until:

error C3859: virtual memory range for PCH exceeded; please recompile with a command line option of '-Zm378' or greater

I usually have this error in my projects and generally set this option in my own CMake scripts, that are a collection of functions for ease of use and dependency management.
It would be nice to be able to pass such options into cotire or have them already in place there.

Cheers,
Moose

It seems that Ninja builds do not detect changes within files included from prefix headers.

The following report on http://www.cmake.org/Bug/view.php?id=1260#c31218 might be expressing the same thing concerning cotire: "...all the solutions mentioned above do not account for the fact that when using the ninja generator, the generated gch in the gcc builds doesn't have any dependency tracking, so if your pch includes some headers, and you alter one of them, the target won't get recompiled at all."

Here is a test case...

CMakeLists.txt is

cmake_minimum_required(VERSION 2.8)
project(test)
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/CMake")
include(cotire)
set_directory_properties(PROPERTIES COTIRE_ADD_UNITY_BUILD FALSE)
add_executable(test stdafx.cpp main.cpp test1.cpp)
set_target_properties(test PROPERTIES COTIRE_CXX_PREFIX_HEADER_INIT "stdafx.h")
cotire(test)

h2.h is

#ifndef H2_H
#define H2_H
#define A 10
#endif

stdafx.h is

#ifndef STDAFX_H
#define STDAFX_H
#include "h2.h"
#define B A
#endif

stdafx.cpp is

#include "stdafx.h"

main.cpp is

#include "stdafx.h"
void test1();
int main() {
    test1();
    return B;
}

test1.cpp is

#include "stdafx.h"
#include <stdio.h>
void test1() { printf("T1: %d\n", B); }

Observe results where touching h2.h does not update the build (at least when using Ninja):

$ cmake -G NInja ..
-- The C compiler identification is GNU 4.8.1
-- The CXX compiler identification is GNU 4.8.1
-- Check for working C compiler using: Ninja
-- Check for working C compiler using: Ninja -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Ninja
-- Check for working CXX compiler using: Ninja -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- cotire 1.5.1 loaded.
-- CXX target test cotired without unity build.
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/proj-test/a
$ ninja -v
1/6] cd /tmp/proj-test && /cmake/bin/cmake -DCOTIRE_BUILD_TYPE:STRING= -P /tmp/proj-test/CMake/cotire.cmake combine /tmp/proj-test/a/test_CXX_cotire.cmake /tmp/proj-test/a/cotire/test_CXX_prefix.hxx stdafx.h
[2/6] cd /tmp/proj-test && /cmake/bin/cmake -DCOTIRE_BUILD_TYPE:STRING= -P /tmp/proj-test/CMake/cotire.cmake precompile /tmp/proj-test/a/test_CXX_cotire.cmake /tmp/proj-test/a/cotire/test_CXX_prefix.hxx /tmp/proj-test/a/cotire/test_CXX_prefix.hxx.gch stdafx.cpp
[3/6] /usr/bin/c++    -include "/tmp/proj-test/a/cotire/test_CXX_prefix.hxx" -Winvalid-pch -MMD -MT CMakeFiles/test.dir/stdafx.cpp.o -MF "CMakeFiles/test.dir/stdafx.cpp.o.d" -o CMakeFiles/test.dir/stdafx.cpp.o -c ../stdafx.cpp
[4/6] /usr/bin/c++    -include "/tmp/proj-test/a/cotire/test_CXX_prefix.hxx" -Winvalid-pch -MMD -MT CMakeFiles/test.dir/main.cpp.o -MF "CMakeFiles/test.dir/main.cpp.o.d" -o CMakeFiles/test.dir/main.cpp.o -c ../main.cpp
[5/6] /usr/bin/c++    -include "/tmp/proj-test/a/cotire/test_CXX_prefix.hxx" -Winvalid-pch -MMD -MT CMakeFiles/test.dir/test1.cpp.o -MF "CMakeFiles/test.dir/test1.cpp.o.d" -o CMakeFiles/test.dir/test1.cpp.o -c ../test1.cpp
[6/6] : && /usr/bin/c++      CMakeFiles/test.dir/stdafx.cpp.o CMakeFiles/test.dir/main.cpp.o CMakeFiles/test.dir/test1.cpp.o  -o test  -rdynamic && :
$ ninja -v
ninja: no work to do.
$ touch ../h2.h
$ ninja -v
ninja: no work to do.

This was tested on Ubuntu 13.10, cmake 2.8.12.1, ninja 1.3.4. It seems to work fine though on make and MSVC generators.

at cotire.cmake:644

set (_compilerExe "${CMAKE_${_language}_COMPILER")

I'm getting a lot of warnings when building my project (https://github.com/luceneplusplus/LucenePlusPlus) on Ubuntu:

...
[ 61%] Building CXX object src/contrib/CMakeFiles/lucene++-contrib.dir/highlighter/SpanGradientFormatter.cpp.o
In file included from :0:0:
/usr/include/stdc-predef.h:59:1: warning: /home/alan/LucenePlusPlus/build/src/contrib/cotire/lucene++-contrib_CXX_prefix.hxx.gch: not used because `lucene' not defined [-Winvalid-pch]
#endif
^
...

The build succeeds, but reports warnings for every source file. I don't get any warnings when building on the Mac (clang) platform.

My best guess at the cause of the problem is that the project is called "lucene++".

I can of course rename my project, but this has big implications with deprecating packages, etc. downstream.

Thanks.

When I run cmake 2.8.9 on my project, I got error:
CUSTOMBUILD : CMake error : Error processing file:y:magus/mgcpp/trunk/cmake/modules/cotire.cmake

This message is print when generate *_unit.CXX file.

For a project I'm working on I recently added a header-only logging system to my project directory (http://easylogging.org/). This significantly increased the compile-time as it's a rather large header (near 6000 lines) that is included in most source files in my project.

However, it seems that due to the standard settings, headers in the source directory are ignored. SInce I didn't install the header on my system, it's in the include directory, which I assume is part of the source directory. Is this correct?

Because I basically only see an increase in compile-time due to the building of the unity targets, but the actual building of the rest of the project seems to take just as long.

Is this even a valid use case scenarior for the use of cotire, or should I be looking at different ways to reduce my compile time? Thanks for your suggestions.

Hi,

I have a large project that builds awesomely quick under cotire, however as all of the install(TARGETS target) macros are still pointing to the original targets, the make install step will compile everything again the old slow way.

There doesn't appear to be an install_unity target, so I was just wondering what you thought the best solution to the problem would be.

Cheers,
Mark

Compiling the cotire Example project creates an empty example_CXX_prefix.hxx file on my machine.

While, as written into the manual, I would expect to have a prefix header with this content:

#pragma warning(push, 0)
#ifdef __cplusplus
#include "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\string"
#include "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\algorithm"
#include "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\iostream"
#endif
#pragma warning(pop)

I'm using Windows 8.1, CMake 3.1.0 and Visual Studio 2013 Professional.
Is it a bug or my fault?

Thanks for the help,
Raffaele.

Hello Sascha,
when i create the unity targets, and do a ninja all_unity the all target is also build.
So actually i build the software twice. Thats not what i want, as this is not faster.
Furthermore unity build with ninja land in a unity subdirectory , so i need to adapt some rules which copy stuff inside the bin dir to be actually able to run my program, how can i easily do this?

Regards,
Gunnar

For some reason after the initial configuration CMakeCache.txt contains:

COTIRE_RC_COMPILER_VERSION:INTERNAL=Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385

Copyright (C) Microsoft Corporation.  All rights reserved.


fatal error RC1107: invalid usage; use RC /? for Help

The offending lines are removed from the cache by cmake on the next run.

Hello,

Is there any way to replace the original targets?
I mean, use the original "make example" instead of "make example_unity"?
This would be quite convenient and could be controlled through a cmake option.
For example, I could have something like:
option(UNITY_BUILD "Enable unity build" OFF)
And when ON, the usual "make" would invoke the cotire targets.

If it's impossible to do this with current cotire, perhaps it could be implemented?

Thanks!
Alexander

Hi

First, thanks for this great module!

I'm using: Ubuntu 10.04, gcc 4.8.1, CMake 3.1.0 build from source

I was using cotire version 1.6.0 and tried all versions up to 1.6.6 and they work correctly
with my build, but after upgrading cotire to 1.6.7 my unity build is broken.
I just replaced cotire and made no modifications to my main CMakeLists.txt
(always completely cleaning build folder).

Problem:
cotire 1.6.7 generates wrong unity files when using COTIRE_MAXIMUM_NUMBER_OF_UNITY_INCLUDES

Setting COTIRE_MAXIMUM_NUMBER_OF_UNITY_INCLUDES to -j2
cotire generates 2 unity files:
cotire/ProjectName_CXX_unity_0_69.cxx
cotire/ProjectName_CXX_unity_70_139.cxx

The second generated file ProjectName_CXX_unity_70_139.cxx
includes exactly the same 70 source code files as ProjectName_CXX_unity_0_69.cxx
(the includes are full paths).

Building without COTIRE_MAXIMUM_NUMBER_OF_UNITY_INCLUDES
works correctly - cotire generates one unity file with all 140 source code files.

Setting COTIRE_MAXIMUM_NUMBER_OF_UNITY_INCLUDES to e.g. -j4
leads to 4 generated files all including the same source code files.

I'll provide additional information If needed.

Thanks
Peter

With CXX=g++ cmake .., strace -f make 2>&1 | grep "extract_indices_CXX_prefix.hxx.gch" gives:

[pid 16833] stat("cotire/extract_indices_CXX_prefix.hxx.gch", {st_mode=S_IFREG|0664, st_size=533075952, ...}) = 0
[pid 16835] access("cotire/extract_indices_CXX_prefix.hxx.gch", R_OK) = 0

However with CXX=clang++ cmake .., I get:

[pid 17543] access("extract_indices_CXX_prefix.hxx.gch", F_OK) = -1 ENOENT (No such file or directory)

The required file exists at cotire/extract_indices_CXX_prefix.hxx.pch, but as you can see, clang++ doesn't try to find it in the subdirectory cotire/, but instead in the current directory (that silently fails). g++ however does look in the subdirectory.

The actual compiler invocations are pretty identical (obtained with make VERBOSE=1):

/usr/bin/g++   -DDISABLE_PCAP -DDISABLE_PNG -DDISABLE_QHULL -DEIGEN_USE_NEW_STDVECTOR -DEIGEN_YES_I_KNOW_SPARSE_MODULE_IS_NOT_STABLE_YET -DFLANN_STATIC -Wno-deprecated -I/usr/include/vtk-5.8 -I/home/niklas/src/pcl/pcl/build/include -I/usr/include/eigen3 -I/home/niklas/src/pcl/pcl/common/include -I/home/niklas/src/pcl/pcl/octree/include -I/home/niklas/openni/OpenNI-Bin-Dev-Linux-x64-v1.5.7.10/Include -I/home/niklas/src/pcl/pcl/io/include -I/home/niklas/src/pcl/pcl/kdtree/include -I/home/niklas/src/pcl/pcl/geometry/include -I/home/niklas/src/pcl/pcl/search/include -I/home/niklas/src/pcl/pcl/visualization/include -I/home/niklas/src/pcl/pcl/sample_consensus/include -I/home/niklas/src/pcl/pcl/filters/include -I/home/niklas/src/pcl/pcl/2d/include -I/home/niklas/src/pcl/pcl/features/include -I/home/niklas/src/pcl/pcl/keypoints/include -I/home/niklas/src/pcl/pcl/ml/include -I/home/niklas/src/pcl/pcl/segmentation/include -I/home/niklas/src/pcl/pcl/outofcore/include -I/home/niklas/src/pcl/pcl/stereo/include -I/home/niklas/src/pcl/pcl/surface/include -I/home/niklas/src/pcl/pcl/people/include -I/home/niklas/src/pcl/pcl/registration/include -I/home/niklas/src/pcl/pcl/recognition/include -I/home/niklas/src/pcl/pcl/tracking/include     -Winvalid-pch -isystem "/home/niklas/src/pcl/pcl/doc/tutorials/content/sources/extract_indices/build/cotire" -include "extract_indices_CXX_prefix.hxx"  -o CMakeFiles/extract_indices.dir/extract_indices.cpp.o -c /home/niklas/src/pcl/pcl/doc/tutorials/content/sources/extract_indices/extract_indices.cpp

/usr/bin/clang++   -DDISABLE_PCAP -DDISABLE_PNG -DDISABLE_QHULL -DEIGEN_USE_NEW_STDVECTOR -DEIGEN_YES_I_KNOW_SPARSE_MODULE_IS_NOT_STABLE_YET -DFLANN_STATIC -Wno-deprecated -I/usr/include/vtk-5.8 -I/home/niklas/src/pcl/pcl/build/include -I/usr/include/eigen3 -I/home/niklas/src/pcl/pcl/common/include -I/home/niklas/src/pcl/pcl/octree/include -I/home/niklas/openni/OpenNI-Bin-Dev-Linux-x64-v1.5.7.10/Include -I/home/niklas/src/pcl/pcl/io/include -I/home/niklas/src/pcl/pcl/kdtree/include -I/home/niklas/src/pcl/pcl/geometry/include -I/home/niklas/src/pcl/pcl/search/include -I/home/niklas/src/pcl/pcl/visualization/include -I/home/niklas/src/pcl/pcl/sample_consensus/include -I/home/niklas/src/pcl/pcl/filters/include -I/home/niklas/src/pcl/pcl/2d/include -I/home/niklas/src/pcl/pcl/features/include -I/home/niklas/src/pcl/pcl/keypoints/include -I/home/niklas/src/pcl/pcl/ml/include -I/home/niklas/src/pcl/pcl/segmentation/include -I/home/niklas/src/pcl/pcl/outofcore/include -I/home/niklas/src/pcl/pcl/stereo/include -I/home/niklas/src/pcl/pcl/surface/include -I/home/niklas/src/pcl/pcl/people/include -I/home/niklas/src/pcl/pcl/registration/include -I/home/niklas/src/pcl/pcl/recognition/include -I/home/niklas/src/pcl/pcl/tracking/include     -Qunused-arguments -isystem "/home/niklas/src/pcl/pcl/doc/tutorials/content/sources/extract_indices/build/cotire" -include "extract_indices_CXX_prefix.hxx"  -o CMakeFiles/extract_indices.dir/extract_indices.cpp.o -c /home/niklas/src/pcl/pcl/doc/tutorials/content/sources/extract_indices/extract_indices.cpp

So I think it must be different behaviour between g++ and clang++ in where they look for these files.

Different versions are specified in the files "CMakeLists.txt" and "README.md" as requirements.
How do you think about to make this detail consistent?

I would like to know if it would be possible to simply replace a target a by a unity target, keeping names and everything just not using original cpp files but the unity cpp files for building.
And this should work for any target in a directory. that would make things a lot simpler, at least for me ;-)

Regards,
Gunnar

For example, want to use the same precompiled header in order to compile many example codes quickly.

Cotire dose not support this function, so I implemented the command shown below by using cotire private commands:

# HACK: shared precompiled header
function(use_shared_pch target origin)
  # origin prefix header
  get_target_property(origin_prefix_header ${origin} COTIRE_CXX_PREFIX_HEADER)

  # make target pch flags
  cotire_make_pch_file_path(CXX ${CMAKE_CURRENT_SOURCE_DIR} ${origin} origin_pch_file)
  cotire_add_prefix_pch_inclusion_flags(
    CXX ${CMAKE_CXX_COMPILER_ID} ${CMAKE_CXX_COMPILER_VERSION}
    ${origin_prefix_header} ${origin_pch_file}
    target_pch_flags
  )
  set_property(TARGET ${target} APPEND_STRING PROPERTY COMPILE_FLAGS ${target_pch_flags})
endfunction()

add_executable(example1 example1.cpp)
cotire(example1)

add_executable(example2 example2.cpp)
use_shared_pch(example2 example1)

add_executable(example3 example3.cpp)
use_shared_pch(example3 example1)

First of all, what a great module, guys! Really helps me a lot, I appreciate that.

One question: I use CMAKE_RUNTIME_OUTPUT_DIRECTORY to place binaries in a custom folder, but I've noticed an empty folder called "unity" is created there each time I regenerate cmake project. Is there any way to get rid of it? Thanks!

Hi,

I incoporated cotire in my cmake project, I get the "gch" file created correctly.
However I see no reduction in compilation time (in fact there is some increase for creating the gch).

The verbose output shows the additional flags: -Winvalid-pch -include "7path-to/file_prefix.h" during compilation of the source files.

My feeling is that the PCH are created but not used. How can I check if the compiler used the PCH ?

I am using GCC 4.8.3,

thank you in advance
filiatra

Hello,

thanks for fixing #27 . Unfortunately this only works for the first level of libs/definitions.
See test case in 029418d .

Implementing dependency walking will be non-trivial because cmake allows circular dependencies (AFAIR). So you need to check if the lib has been seen before or not.

I wonder if there is an easier way of getting all the includes/definitions. Have you asked in the mailing list?

Thanks,
Gregor

If CMAKE_OSX_ARCHITECTURES is not set then cotire passes -arch with not architectures to the compiler command line. This is an error.

Hello,

the current version of cotire does not work with target usage requirements in cmake (see [1]). I created a test case in @f1bf25c538b7bbfc80c57c58a6de1dd233eb5b4e.

The problem is that includes (and most probably definitions) from target dependencies are not picked up. In my test case I get an error about acme.h not found due to the missing acme include path.

Thanks,
Gregor

[1] http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html#target-usage-requirements

It randomly started to generate this error for every single file in a MSVC11 build.
Build log: http://pastebin.com/1kFFF4v0

If a user uses Windows.h but specifies NOMINMAX, then cotire discards the NOMINMAX since cotire includes Windows.h in the PCH before a user gets a chance to define NOMINMAX.

See the fix that one user has used here: https://github.com/p-jackson/uiglue/blob/master/curt/include_windows.h#L33

• cmake version 2.8.12.1
• using "NMake Makefiles" generator with Visual Studio 2013
• cotire 1.5.1

I am creating a static library with precompiled headers.
If I have a source file in a subdirectory (e.g. "component/foo.cc"),
I'll get a compiler error C2859:

• "pdb is not the pdb file that was used when this precompiled header was created, recreate the precompiled header"

Everything works fine if I move the file to the current directory (e.g. "foo.cc").

Thanks for this great module! I've really been suffering from long compilation times and this is promising to be really good. An issue, though. I have something like this:

cmake_minimum_required(VERSION 2.8.11)

list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/CMake)
include (cotire)
file(GLOB_RECURSE COMMON common/*)
add_library(common ${COMMON})
cotire(common)

The target is cotired properly:

-- CXX target common cotired.

However, if I do

ninja common_unity

The target gets built without generating any precompiled headers! Doing

ninja common_pch

does generate the headers, so that step works, it's just that in the process of actually building the target, they aren't generated, so I assume they aren't actually being used in the compilation process.

Further, I have a target that depends on common (among other things):

source_group(simplewallet FILES ${SIMPLEWALLET})
add_executable(simplewallet ${SIMPLEWALLET})
target_link_libraries(simplewallet common)

If I do the following:

set_target_properties(simplewallet PROPERTIES COTIRE_UNITY_LINK_LIBRARIES_INIT COPY_UNITY)
cotire(simplewallet)

Then building simplewallet_unity doesn't generate any precompiled header files. Interestingly, if I do COPY instead of COPY_UNITY, then the precompiled header files do get generated.

Please have a look for https://codereview.qt-project.org/#change,34052 (Patch Set 9).
I try to use cotire for QtCreator build, but it failed.
It can't get some flags or defines from Qt5.
Any comments?

With Cotire 1.6.9:

We have a shared library that, for one reason or another, needs to be named with a .so extension, even on Windows (it's a ruby extension). As such, we set the PREFIX, SUFFIX, IMPORT_PREFIX, and IMPORT_SUFFIX target properties, like so:

set_target_properties(libfacter PROPERTIES PREFIX "" SUFFIX ".so" IMPORT_PREFIX "" IMPORT_SUFFIX ".so.a" ...)

When not using unity, this builds libfacter.so and libfacter.so.a as expected. When using a unity build for this target, however, we get libfacter.so and liblibfacter.dll.a. Cotire seems to be causing it to ignore the import library prefix and suffix properties.

I know Windows system header files are not compatible, the "Winsock2.h" must be ahead of "Windows.h", but the product preheader file not promise it. So, the source will not complied well.

Boost library is conflict with cotire.

cc1plus: attention : /home/rezgui/Bureau/workspace/opossum/build/src/cotire/opossum_CXX_prefix.hxx.gch: n'est pas utilisé parce que « OPTIMIZE » n'est pas définie [-Winvalid-pch]
In file included from /home/rezgui/Bureau/workspace/opossum/include/boost/math/policies/policy.hpp:22:0,
from /home/rezgui/Bureau/workspace/opossum/include/boost/math/tools/precision.hpp:19,
from /home/rezgui/Bureau/workspace/opossum/include/boost/math/special_functions/acosh.hpp:20,
from /home/rezgui/Bureau/workspace/opossum/include/boost/math/special_functions.hpp:15,
from /home/rezgui/Bureau/workspace/opossum/include/boost/random/generate_canonical.hpp:22,
from /home/rezgui/Bureau/workspace/opossum/include/boost/random.hpp:52,
from /home/rezgui/Bureau/workspace/opossum/src/network.hpp:40,
from /home/rezgui/Bureau/workspace/opossum/src/network.cpp:27:
/home/rezgui/Bureau/workspace/opossum/include/boost/math/tools/config.hpp:283:7: erreur: ‘fexcept_t’ does not name a type
/home/rezgui/Bureau/workspace/opossum/include/boost/math/tools/config.hpp: In constructor ‘boost::math::detail::fpu_guard::fpu_guard()’:
/home/rezgui/Bureau/workspace/opossum/include/boost/math/tools/config.hpp:275:27: erreur: ‘m_flags’ was not declared in this scope
/home/rezgui/Bureau/workspace/opossum/include/boost/math/tools/config.hpp:275:36: erreur: ‘FE_ALL_EXCEPT’ was not declared in this scope
/home/rezgui/Bureau/workspace/opossum/include/boost/math/tools/config.hpp:275:49: erreur: ‘fegetexceptflag’ was not declared in this scope
/home/rezgui/Bureau/workspace/opossum/include/boost/math/tools/config.hpp:276:37: erreur: ‘feclearexcept’ was not declared in this scope
/home/rezgui/Bureau/workspace/opossum/include/boost/math/tools/config.hpp: In destructor ‘boost::math::detail::fpu_guard::~fpu_guard()’:
/home/rezgui/Bureau/workspace/opossum/include/boost/math/tools/config.hpp:280:27: erreur: ‘m_flags’ was not declared in this scope
/home/rezgui/Bureau/workspace/opossum/include/boost/math/tools/config.hpp:280:36: erreur: ‘FE_ALL_EXCEPT’ was not declared in this scope
/home/rezgui/Bureau/workspace/opossum/include/boost/math/tools/config.hpp:280:49: erreur: ‘fesetexceptflag’ was not declared in this scope
make[3]: *** [src/CMakeFiles/opossum.dir/network.cpp.o] Erreur 1

This is what should be mocced:

$ rm `ls src/*moc*`
$ ninja qtwallet_automoc
(2.929s) [0/0/1] Automoc for target qtwallet
Generating bitcoin.moc
Generating intro.moc
Generating overviewpage.moc
Generating rpcconsole.moc
Generating moc_addressbookpage.cpp
Generating moc_addresstablemodel.cpp
Generating moc_askpassphrasedialog.cpp
...
Generating moc_walletframe.cpp
Generating moc_walletmodel.cpp
Generating moc_walletview.cpp

But with unity, the first few are skipped:

$ rm `ls src/*moc*`
$ ninja qtwallet_unity_automoc
(2.546s) [0/0/1] Automoc for target qtwallet_unity
Generating moc_addressbookpage.cpp
Generating moc_addresstablemodel.cpp
Generating moc_askpassphrasedialog.cpp
....
Generating moc_walletframe.cpp
Generating moc_walletmodel.cpp
Generating moc_walletview.cpp

The bitcoin.moc, intro.moc, etc., are included in the cpp files, e.g. #include "bitcoin.moc", whereas the moc_*.cpp are auto-generated from the presence of slots and signals.

Work-around for now is:

add_dependencies(qtwallet_unity qtwallet_automoc)

Hi, thanks for the great project.
There is an issue using Cotire(v1.2) with Xoreax Incredibuild(v3.6, v4.5).
It looks like that Incredibuild can’t generate unity file and prefix headers.
This problem also exist when use manual generated precompiled headers.

Using Cotire without Incredibuild works great.
Cotire configuration is simple:
SET(PROJECT Utils.Cpp98)
...
SET(BUILD_TYPE SHARED)
...
COTIRE(${PROJECT})

But if we use Visual Studio compiler it work fine. Incredibuild and msbuild logs:

--------------- Visual studio compiler (without Incredibuild) --------------------------------
1>------ Rebuild All started: Project: ZERO_CHECK, Configuration: Debug Win32 ------
1>Deleting intermediate and output files for project 'ZERO_CHECK', configuration 'Debug|Win32'
1>Checking Build System
1>CMake does not need to re-run because D:/engine/.build/CMakeFiles/generate.stamp is up-to-date.
1>CMake does not need to re-run because D:/engine/.build/engine/Utils/CMakeFiles/generate.stamp is up-to-date.
1>CMake does not need to re-run because D:/engine/.build/engine/Utils/Lz4/CMakeFiles/generate.stamp is up-to-date.
1>Build log was saved at "file://d:\engine.build\ZERO_CHECK.dir\Debug\BuildLog.htm"
1>ZERO_CHECK - 0 error(s), 0 warning(s)
3>------ Rebuild All started: Project: Utils.Cpp98, Configuration: Debug Win32 ------
3>Deleting intermediate and output files for project 'Utils.Cpp98', configuration 'Debug|Win32'
3>Performing Pre-Build Event...
3>Generating CXX unity source engine/Utils/Debug/cotire/Utils.Cpp98_CXX_unity.cxx <!-- GENERATE UNITY FILE
3>Generating CXX prefix header engine/Utils/Debug/cotire/Utils.Cpp98_CXX_prefix.hxx <!-- GENERATE PREFIX FILE
3>Building Custom Rule D:/engine/code/cpp98/Utils/CMakeLists.txt
3>CMake does not need to re-run because D:\engine.build\engine\Utils\CMakeFiles\generate.stamp is up-to-date.
3>Compiling...
3>ClLog.cpp
............ a lot of .cpp, but compilation successful ..........

---------------------- Incredibuild(probably it can’t generate unity and prefix file -------------------------
Initializing...
Deleting intermediate files and output files for project 'ZERO_CHECK - Debug|Win32'
Deleting intermediate files and output files for project 'Lz4 - Debug|Win32'
Deleting intermediate files and output files for project 'Utils.Cpp98 - Debug|Win32'
--------------------Configuration: ZERO_CHECK - Debug|Win32--------------------
Checking Build System
CMake does not need to re-run because D:/engine/.build/CMakeFiles/generate.stamp is up-to-date.
CMake does not need to re-run because D:/engine/.build/engine/Utils/CMakeFiles/generate.stamp is up-to-date.
CMake does not need to re-run because D:/engine/.build/engine/Utils/Lz4/CMakeFiles/generate.stamp is up-to-date.
--------------------Configuration: Utils.Cpp98 - Debug|Win32--------
Performing Pre-Build Event...
--------------------Build System Error-----------------------------------------
Fatal error:
Task queue management failed.
<- Precompiled header define map unavailable (x:\Dev\ib\VCDepEvalTask.pas, line 357)

1 build system error(s)

Hi. I am having troubles with index file generation for PCH. Header files in ${CMAKE_SOURCE_DIR} (which are actively modified and thus not to be precompiled) are added to the index file.
Trying with a minimal example (main.cpp, other.h) and setting COTIRE_VERBOSE to ON I got this output:

[ 50%] Generating CXX prefix header cotire/test_CXX_prefix.hxx
-- test_CXX_prefix.hxx does not exist yet.
-- execute_process: E:/misc/clang/bin/clang++.exe;-H;-E;C:/Users/claudio/Desktop/build/cotire/test_CXX_unity.cxx
-- Scanning 102 unique lines of 102 for includes
-- Ignored extensions: C;M;c++;cc;cpp;cxx;m;mm;CPP;inc;inl;ipp
-- Ignored paths: C:/Users/claudio/Desktop/test;C:/Users/claudio/Desktop/build
#ifdef __cplusplus
#include "C:\Users\claudio\Desktop\test\other.h"
#include "E:\misc\clang\include\c++\4.6.3\iostream"
#include "E:\misc\clang\include\c++\4.6.3\functional"
#include "E:\misc\clang\include\c++\4.6.3\algorithm"
#endif

Even if C:/Users/claudio/Desktop/test is included in ignore paths, C:\Users\claudio\Desktop\test\other.h is not ignored. I assume the problem is that the former uses forward slashes and the latter backslashes (however I can not check on a non Windows system).

If I explicitly add C:\Users\claudio\Desktop\test to ignored paths it complains that \U is not a valid escape sequence. The same with C:\\Users\\claudio\\Desktop\\test. The same with C:\\\Users\\\claudio\\\Desktop\\test. The same with C:\\\\Users\\\\claudio\\\\Desktop\\\\test.

Being able to generate one compilation unit per processor core would be really useful. Is there any plan to implement this? I might look at the code myself, but my cmake skills (being new to it) are rudimentary at best. I had one compilation unit per core setup in my previous Makefile project though, and it worked nicely.

.cpp file doesn't get added to the _unity.cxx file when PCH is turned off and ,COTIRE_MINIMUM_NUMBER_OF_TARGET_SOURCES is 0.

In cotire.cmake line 1611:
# there is only a single unity file
cotire_make_single_unity_source_file_path(${_language} ${_target} _unityFiles)

I think _unityFiles should be replaced with _sourceFiles.

hello. I try to make the examples on Ubuntu and encounter the following issue. I have the requirements for Cmake version, GCC installed, not Intel C++ Compiler. I may not understand how GCC/Intel C++ Compiler works, but does this require Intel C++ compiler on top of GCC?

Thanks

Hi,
first of all thanks for this great cmake module. I use it for precompiled header generation a longer time now.
Using qt 5.5.0 git, cmake 3.2.1 , corire 1.7.0
Now i started to use unity build and ran into this error:
linking fails because of duplicate symbols. metatypes symbols being multiple defined . this comes from
lining src/MyProgram/CMakeFiles/MyProgram_unity.dir/MyProgram_automoc.cpp.obj and src/MyProgram/CMakeFiles/MyProgram_unity.dir/MyProgram_unity_automoc.cpp.obj

I fixed that by removing lines 2745 and 2746:
#list (APPEND _unityTargetSources "${_target}_automoc.cpp")
#set_property (SOURCE "${_target}_automoc.cpp" PROPERTY GENERATED TRUE)

But i think these lines serve some purpose. maybe it is only needed if COTIRE_UNITY_LINK_LIBRARIES_INIT is NOT COPY_UNITY?

Regards,
Rodion

Currently if a system header file included in a generated pch file gets trivially changed (like new write date without modifications) clang errors due to

fatal error: file '/usr/include/pthread.h' has been modified since the precompiled header '...' was built
note: please rebuild precompiled header '...'

Is there someway cotire could add checks so that it rebuilds them if needed? compiling an empty file with included pch seems to be a valid check for it.

I'm using your library in few of my projects, and it works great. However recently I had to manually set the PCH header file, using your new option in 1.2.0. One urgent issue for me is that it does not set the right C or CPP file as the PCH creator. For ex: if I set manually the header "stdafx.h" the CPP used to create the PCH is not "stdafx.cpp", but in my case it is a file with the same name as the project. Could you please fix this?

One more issue: sometimes I need to disconnect the project files from CMake (CMAKE_SUPPRESS_REGENERATION) and I add manually a second platform target (ex: x64). However, you use for storing the PCH a custom path and not the temporary folder used by the compiler and the path u use is containing only the type of build (Release or Debug) and not the platform name also. In this case with multiple platforms, it overwrites the PCH on different platforms so each time the platform is changet the WHOLE project recompiles. Please use for PCH the project temporary folder $(IntDir), or add the platform name to the custom folder (in my opinion the first is more elegant and easy, and will also allow us to clean the project very easy by deleting only one folder of intermediate objects).

Thanks!

This error occurs during initial CMake configure.

CMake Error at CMake/cotire.cmake:1587 (set_property):
set_property could not find TARGET APPEND_STRING. Perhaps it has not yet
been created.
Call Stack (most recent call first):
CMake/cotire.cmake:2127 (cotire_setup_target_pch_usage)
CMake/cotire.cmake:2207 (cotire_target)
src/CMakeLists.txt:10 (cotire)

OS: Ubuntu 11.10 32bit cmake version 2.8.5 gcc 4.6.1

reproduced on CotireExample

Thanks.

Hi,

I have two kind of projects:

1. Projects under manual development(I change different files, compile, etc)
2. Projects consist of generated files(if I make changes in generator it affects all files in such projects)

Is it possible to apply pch technique for the first group of projects and unity for the second?

Thanks.

Is it possible to make cotire looking inside the current project for headers and precompile them?

A static library target with the property "position_independent_code" set to "true" will compile the headers missing the -fpic setting. Thus compiling gives the following gcc 4.6.3 warning:

cc1plus: warning: foo.gch: created and used with different settings of -fpic