file(COPY_FILE) could be confusing, could augment file(CONFIGURE) instead
In !5885 (merged), a new file(COPY_FILE)
subcommand was added. In this comment, it was stated that other than error reporting, the only difference between using file(COPY_FILE)
and configure_file()
is that the latter adds a dependency whereas the former doesn't.
One of the problems with a subcommand named file(COPY_FILE)
is that it is really close to file(COPY)
. From a user's perspective, they seem like they are or should be doing the same thing, it's just that COPY
is more general. It makes COPY_FILE
seem unnecessary. I started wondering if there was a way we could avoid that. Then I realised that we already have file(CONFIGURE)
, it's just that it currently lacks support for a COPYONLY
keyword (which configure_file()
has) and only supports CONTENT
and not INPUT
(file(GENERATE)
supports both, the latter being a way to specify a file as the source). The ONLY_IF_DIFFERENT
keyword for file(COPY_FILE)
seems to make it behave just like configure_file()
with the COPYONLY
keyword. So I'm wondering if rather than adding a new file(COPY_FILE)
subcommand, could we instead expand file(CONFIGURE)
by adding support for COPYONLY
and INPUT
keywords? It would seem to offer some advantages:
- Doesn't introduce confusion between
file(COPY)
andfile(COPY_FILE)
. - Greater consistency between
file(CONFIGURE)
andfile(GENERATE)
. - Greater consistency between
file(CONFIGURE)
andconfigure_file()
. In fact, the latter may well become redundant and could potentially even be deprecated.
To support the original use case that motivated the new file(COPY_FILE)
subcommand, file(CONFIGURE)
could also gain support for a RESULT
keyword.