I have another feature request regarding the CMake setup. With
autotools, one gets a config.status file that when run recreates a
configuration including all the configure options. That's quite
handy, and not for the least because one can easily check how
exactly one ran configure last time (prefix, debug enabled, etc.)
Can we add something like that to the CMake setup? I'm thinking all
it needs to be is actually the exact configure call written into a
file and made executable. However, ideally that would not end up in
the build directory because they it won't survive a make distclean.
Why doesn't the CMakeCache.txt file work? If you run cmake again with an
exisiting CMakeCache.txt it should do exactly that.
Maybe we could add an option to the configure script to just re-run
cmake without changing and settings?
I don't really like to have anything created during build-time that's
not in build. This would be the only file that lives outside of build.
And AFAIK the config.status files get's deleted when you do a "make
distclean". (As it should, since distclean should get you to a the point
you had just after extracting the distribution tarball).
Because it doesn't show me the original configure parameters (which
is also very convienient for copy&paste, say over to a different
machine rather than having to copy the cache, which may or may not
work).
And AFAIK the config.status files get's deleted when you do a "make
distclean".
Yeah, I know, and I should have written "rm -rf build" instead of
"make distlean". But ok, I think I can live with having this file
being generated inside the build directiory.
> And AFAIK the config.status files get's deleted when you do a "make
> distclean".
Yeah, I know, and I should have written "rm -rf build" instead of
"make distlean". But ok, I think I can live with having this file
being generated inside the build directiory.
I was also going to agree with Gregor's rationale of not polluting the source tree. Plus if one wants to use a single source tree for multiple build trees, then you either have to overwrite the config.status or start disambiguating like config.status.${builddir}.
But yeah, I should be able to get it to create config.status's in build dirs.
the source tree. Plus if one wants to use a single source tree for
multiple build trees, then you either have to overwrite the
config.status or start disambiguating like
config.status.${builddir}.
Good point.
But yeah, I should be able to get it to create config.status's in build dirs.
