search

nanoant / CMakePCHCompiler

CMake precompiled header support via custom PCH compiler extension
MIT License
103 stars 20 forks source link

CMakePCHCompiler doesnt check for header dependency updates #7

Closed lolidontknowwhatimdoing closed 5 years ago

lolidontknowwhatimdoing commented 9 years ago

hi,

I use CMakePCHCompiler to generate a pch file from a header file which points to a number of sub header files. One problem I've been facing is that when I update one of my subheaders, cmake doesn't seem to know that it needs to recompile the main header file into pch. as a result I will frequently deal with compilation issues unless I do a make clean.

If there are any already built-in features which i am not aware of that will cause the main pch file to recompile after some manually speciified file changes, please let me know.

Thanks in advance.

kdsx commented 7 years ago

It seems like this is not the only dependency tracking issue. Target does not depend on the precompiled header too. E.g. if I modify the precompiled header the target is not rebuilt.

m-7761 commented 7 years ago

@lolidontknowwhatimdoing @kdsx This is normal behavior for PCH files under Visual Studio. I can tell you after doing extensive work on this module ( https://github.com/nanoant/CMakePCHCompiler/pull/13 ) that there isn't a way to support this behavior, and even if CMake adds native PCH files, many users will be frustrated if PCH files build themselves because of header changes, because often PCH files take a long time to build (they can be many gigabytes in size) and I think this is why MSVC requires manual intervention.

In MSVC user Rebuild, which does a Clean operation I think; and if not use Clean. With CMake, user /fast and use the -B option with make, either on the command-line or edit it into the IDE widgets. (I wish that CMake would add -B to the /fast rules when generating widgets. I've taken this up with them in the PCH discussion there: https://gitlab.kitware.com/cmake/cmake/issues/1260)

m-7761 commented 6 years ago

I think this can be closed somehow with "Won't Fix" if not to hide it. The only way I could see this being fixed is with a manual option. Because (see my earlier comments) it would be super annoying if this were the default behavior.

Besides, this is beyond the scope of this module. A native CMake implementation might contemplate such a feature (do modules have access to deep dependency information?) however this module should cater to users truly at a loss without a PCH solution.

nanoant commented 5 years ago

Closing as "won't fix" as this is far beyond scope of this module.