[cmake-developers] Listing source-tree files encountered (was: Wrapping functions in CMake)

[Clifford Yapp]

On Wed, Jul 15, 2015 at 9:10 AM, Brad King <brad.king at kitware.com> wrote:
> On 07/09/2015 01:35 PM, Clifford Yapp wrote:
>> 1.  First, we need to maintain a list of all files in the source
>> repository that are known to the build system.  To do this we maintain
>> a global list of files, define a custom CMAKEFILES command to allow us
>> to manually specify miscellaneous files as "known", and override all
>> of the primary target creating commands to add their files to the list
>> (for example, add_executable is passed a list of source files, and all
>> of those files are automatically added to the "known files" list by
>> the function override of add_executable.)  This list is used for both
>> our "make-clean-in-src-dir" feature and our distcheck build target
>> (which does a number of verification steps using the version control
>> system, the build system and the files-on-filesystem information to
>> make sure the build logic is current.)
>
> These days it is the job of version control tools to know what files
> are part of the source and what files are not.  Commands like "git clean"
> are then responsible for cleaning out a source tree, not the build system.

Maybe we're a bit "retro", but we've got a system set up which uses
the VCS (subversion, in our case) to cross check the build system's
awareness of files.  We have a number of reasons for this approach,
which I can go into if anyone's interested, but the punchline is we've
implemented our own "distcheck" system which has a number of (for our
project, at least) important features.

> CMake is mainly designed for out-of-source builds where nothing in the
> source tree is touched at all.  This makes distclean unnecessary.
> We support in-source builds for end-user convenience when installing
> a project from a source tarball, but in general development should
> always be done with out-of-source builds to keep the source pristine.

Agreed, but since historically we've allowed in-src-dir builds (in the
dark old days that's actually the only way things worked for us, but
that's another story) the decision was made to continue support for
them.  It just so happened that the system we implemented to support
distcheck was also the primary piece needed to make in-src-dir
practical, so in the end we opted to support it and one of our
distcheck test targets is set up specifically to ensure it keeps
working.

>> 1.  Have CMake internally maintain a list (or maybe per-command lists
>> for more flexibility) of all files with paths relative to the root
>> source directory that have been "observed" by add_executable,
>> add_library, add_custom_target, add_subdirectory, and configure_file
>> that can be accessed via CMake variables
>
> Many of the source file locations are not actually determined until
> generate time, so a configuration-time list is not possible to
> implement reliably in general.  Maintaining the list would force
> source file locations to be finalized too early.

Lists that contains a verbatim collection of all path specifiers,
regardless of form, that are passed to the various add_* targets would
be enough, I think - it'd then be up to our own CMake logic to make
sense of it all.  I'm not hoping to push our whole
in-src-dir/distcheck system into mainstream CMake, just looking for a
way to achieve the current result without requiring the
built-in-command overrides - I think collecting raw lists of paths
supplied to targets is the key piece that is currently driving the
command overrides.

Would such "verbatim transcription" lists (un-resolved path specifiers
and all) be something that could be provided?

Thanks,
CY