On Thu, May 30, 2013 at 08:27:28AM +0200, Michael Wild wrote:
> Also, very astonishing to me is the fact that after apparently finding
> file(GLOB) in the documentation, you clearly didn't read the whole
> paragraph. It's right there:
>
> >> We do not recommend using GLOB to collect a list of source files
> >> from your source tree. If no CMakeLists.txt file changes when a
> >> source is added or removed then the generated build system cannot
> >> know when to ask CMake to regenerate.
>
> As you are so fond of clear violations: You failed to RTFM...
> (http://en.wikipedia.org/wiki/Rtfm)
Have you ever assumed, when crossing a street you know very well, that
cars will only come from one side and neglected to look in the other
direction ?
I needed a function to glob, I read the signature and went on to use it.
I did notice that in the documentation later.
> Besides, you seem to be very sure that CMake is the *only* tool that
> prefers explicit source file listing.
Nope.
> Have you ever used any of the popular IDE's? Visual Studio? Xcode?
> Eclipse? They all create explicit list of files in their projects.
An IDE is a different class of tool, that builds on top of tools such as
CMake. Apples and oranges.
> What are the (not so serious) pros and cons of GLOB, even if it worked
> the way you think it should?
>
> Pro:
> * laziness
You say it, like it's a bad thing.
> Con:
> * laziness
> * extremely error prone:
> - picks up scratch files
> - works for you but breaks for others because you forgot to commit a
> file
> - breaks for you because the other dude forgot to commit his file
> * makes it unnecessarily difficult to exclude files from the build
> - temporarily: for testing (you'd need to move the file away and then
> remember to move it back; error prone again)
> - permanently: dependent on the platform, configuration, enabled
> capabilities etc. And using #ifdef's for this is bad because you
> still invoke the compiler and waste time to just compile an "empty"
> file.
> * when reading the build system code, you have to switch context in
> order to determine the files included in the build.
We've been through all these points earlier in this thread.
> On the other hand, initially creating and then maintaining an explicit
> list of files is easy. Initially I usually create the list of files like
> this using vim:
>
> :r !cd $(dirname %); ls **/*.{c,cpp}; ls **/*.{h,hpp}
It's not about the difficulty of creating a file list.
WK
--
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
