On 2013-05-19 19:47, Wojciech Knapik wrote:
I you ever put "junk files" with, say, a .cpp extension in a source tree
of a C++ project, you're the only one to blame.

This is not unusual at all. I'm often in the situation where I have source files for classes that are works in progress, tangent thoughts that I don't want to get rid of, or for whatever other reason are still floating around (generally not committed). That doesn't mean I want to build them.

Worse, I may have source files that should only be built on certain platforms or if certain features are enabled. There may be reasons why it is not desirable to have these in a different location.

Another not-uncommon scenario is leftover generated source files in the build directory, e.g. because I switched to a branch that doesn't have a class for which files were previously generated. Possibly these would *always* be explicitly listed, but if not, I would have to remove my build directory on switching branches to avoid build errors.

With explicit lists, none of these cases pose a problem.

For how many people learning CMake is it predictable, or intuitive, that
GLOBs will only be expanded when generating the build system ?

GLOB is just one of many things that will surprise you when working with CMake if you don't understand the difference between the configure and build passes.

In order for glob-based file lists to ever fully work would require either (a) re-evaluating the globs at every build in order to determine if CMake needs to re-run, or (b) always re-running CMake.

(b) is just plain unacceptable for projects that take a non-trivial time to configure (e.g. VTK, although most non-trivial projects take at least several seconds).

(a) is probably not possible in a portable manner without doing it from within CMake, and even still will likely increase no-op build time by a non-trivial amount, especially for e.g. Ninja which otherwise does extremely fast no-op builds.

Wait, are you saying that expanding GLOBs is so slow, that it would have
a noticeable impact on your build time ?

Compared to a ninja no-op build? I don't have numbers, but I wouldn't be surprised if it's less unnoticeable than you think.

--
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

Reply via email to