[cmake-developers] Severe regression caused by #14972 fixes

Amine Khaldi amine.khaldi at reactos.org
Wed Oct 8 03:45:16 EDT 2014


> This will not be done before the freeze for 3.1 on Thursday.
> Reverting 7243c951 will resolve the problem for ReactOS in
> out-of-source builds.  So, we either revert that or hope Ninja can
> be fixed to deal with the large dependency lists w/out crashing.

In the discussion with Adam, he mentioned (about input files) that CMake can not know that some file will always exist or not, and that it doesn't know files is generated unless someone tells that, *unfortunately some projects don't*

Reverting this change makes more sense, because CMake has always been advertised as being designed for out-of-source builds, and we cannot penalize every single sane CMake user out there simply because some projects do not properly mark their generated input files (in custom commands) as GENERATED.

I don't understand why is it okay for the CMake project (at least in ReactOS case) to introduce now a (very) huge list of our codebase *source files* (files that exist in our *repo* and not *generated* nor we can even *assume* they may not exist at some point, because they will *always* exist) simply to solve a problem that is, if some projects do *not* properly use CMake (GENERATED property, adding dependencies properly on commands/target that generate the said input files...etc) we need to do this to keep them working.

The extra bloat of generating a very large list of phony rules on *source* files to solve a CMake misuse problem suggests that we're Doing It Wrong.

If ninja didn't crash on us, we would probably never find out about this bloat, unless some of us randomly had the idea of diffing the old build log (from CMake 2.8.x) with this new one.




More information about the cmake-developers mailing list