On 2013-05-28 19:50, Wojciech Knapik wrote:
Files don't just happen to be lying around in directories. You have to
create them in a specific path, with a specific name. Even if the act of
creation was performed by another developer, on another machine, that
information is written to disk in the course of a VCS checkout.
IOW, you are claiming that *the VCS* is authoritative. (Personally I
would claim, at least as things stand now, that CMakeLists.txt is
authoritative, and any discrepancies with the files on disk represent
mistakes.)
...which (see more below) is actually an interesting idea.
The contents of the directory rules. If you remove a file from it,
there's nothing you can do in a CMakeList to help it. If you add a file
to it and you use GLOBs, there's nothing that you need to do in a
CMakeList for it to be built. (*)
In practice, developers *are* going to create 'scratch' files in source
directories. Or forget to add new files when committing.
In the latter case, at least having CMakeLists.txt specifically ask for
the file will make it much more immediately obvious when this mistake
happens.
If there were a way to ask *the VCS* for the file list, I could see that
being useful; it would avoid the problem with 'scratch' files, and would
also help prevent forgetting to add files (since the developer would get
broken functionality at least until staging the addition). But of course
this would need to degrade gracefully when dealing with release
tarballs. (Ideally the release tarball would use an explicit list.)
Having an explicit list also helps guard against accidental deletion by
requiring an explicit change when a file should no longer be part of the
build. Using the VCS's expected file list could also serve this purpose,
but this would be another argument for at least source tarballs to use
explicit lists.
What's the point of GLOBs anyway if you only reliably expand them once ?
I have often thought that GLOB is more dangerous than useful :-).
(Especially as I can't think of having ever used it.)
Who wants a snapshot of the past state of a location on disk in a build
system ?
They're potentially useful for operations performed at configure time,
at which point they are current. If you're persisting them into the
build rules without some way of checking if they are still correct, then
you're doing it wrong :-).
On Thu, May 23, 2013 at 01:13:12PM -0400, David Cole wrote:
People who are not used to CMake (perhaps) don't realize that when you
edit a CMakeLists file, or any of its inputs, the expectation is that
simply typing "make" will do a build, re-running cmake as needed, and
only when needed.
What's so special about CMake, that it's ok for you guys to break that
principle, but not ok for others ?
Really? Autotools is the same way (except I think they just break when
the autotools chain needs to be re-run, rather than trying to make it
happen automagically).
To some extent, anything with a configure script is the same way...
Does this really only 'bother' people using CMake? (And if so, why?
Honest question...) Or do other build systems have the same problem?
When somebody asks about "GLOB," we CMake devs have a learned "GLOBs
are evil, don't use them" response that we make out of habit.
If you take a step back, forget about the CMake internals for a moment
and read that sentence again - does it sound ok to you ?
Er... mostly. Say better, GLOB is not something you should use unless
you really know what you are doing with it, why you need it, and how to
use it correctly.
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
