You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The make build outputs horribly long compile commands, with all the options we use, repeated for every file we compile. Instead, we can potentially write those options to a Response File, and reference it in the build command. We maybe want to output the response file once, at the start of the build, so we can see the options, but won't need to repeat them all for every file we compile. This should produce much cleaner output.
Additionally, the Response File will have a modification time on it. By setting it as a dependency for the output files, we can trigger a rebuild if any of the compile options change. This would be better than the current system which won't detect changes to compile options, and so won't trigger a rebuild if a compile flag has changed.
Support for compiling should be easy enough, since only the first dependency (the .cpp file) is sent to the compiler, with other dependencies only being used by make. Support for linking may be more tricky, or require some filtering, since all dependencies are sent to the linker (.obj and lib*.a).
To avoid excessive rebuilds, we'd need to only update the Response File when the contents change. More specifically, we want to only update the time-stamp on the Response File when the contents change. That way it can only trigger rebuilds when flags are actually updated. For that we may need a way to compare the new contents with the old contents, and only write the file if they do not match.
It seems Response Files are supported by GCC, Clang and MSVC, though admittedly there doesn't seem to be any documentation regarding Clang support. Clang support may need some verification. I would expect MingW to support the same options as GCC, though we may also want to verify that too.
Was just looking into the problem of preserving the modification time of the response file in case it didn't need to change. It's possible to read the response file into a variable using variable=$(<filename), which can then be compared to the generated expected file, and only write to the file if the strings are different.
The
make
build outputs horribly long compile commands, with all the options we use, repeated for every file we compile. Instead, we can potentially write those options to a Response File, and reference it in the build command. We maybe want to output the response file once, at the start of the build, so we can see the options, but won't need to repeat them all for every file we compile. This should produce much cleaner output.Additionally, the Response File will have a modification time on it. By setting it as a dependency for the output files, we can trigger a rebuild if any of the compile options change. This would be better than the current system which won't detect changes to compile options, and so won't trigger a rebuild if a compile flag has changed.
Support for compiling should be easy enough, since only the first dependency (the
.cpp
file) is sent to the compiler, with other dependencies only being used bymake
. Support for linking may be more tricky, or require some filtering, since all dependencies are sent to the linker (.obj
andlib*.a
).To avoid excessive rebuilds, we'd need to only update the Response File when the contents change. More specifically, we want to only update the time-stamp on the Response File when the contents change. That way it can only trigger rebuilds when flags are actually updated. For that we may need a way to compare the new contents with the old contents, and only write the file if they do not match.
It seems Response Files are supported by GCC, Clang and MSVC, though admittedly there doesn't seem to be any documentation regarding Clang support. Clang support may need some verification. I would expect MingW to support the same options as GCC, though we may also want to verify that too.
External reading:
The text was updated successfully, but these errors were encountered: