Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The best way to specify sourcefiles in CMake is by <strong>listing them explicitly</strong>.</p> <p>The creators of CMake themselves advise <strong>not</strong> to use globbing.</p> <p>See: <a href="http://www.cmake.org/cmake/help/v3.3/command/file.html?highlight=glob#file" rel="noreferrer">http://www.cmake.org/cmake/help/v3.3/command/file.html?highlight=glob#file</a></p> <blockquote> <p>(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.)</p> </blockquote> <p>Of course, you might want to know what the downsides are - <em>read on!</em></p> <hr> <h2>When Globbing Fails:</h2> <p>The big disadvantage to globbing is that creating/deleting files won't automatically update the build-system.</p> <p>If you are the person adding the files, this may seem an acceptable trade-off, however this causes problems for other people building your code, they update the project from version-control, run build, then contact you, complaining that<br><strong>"the build's broken".</strong></p> <p>To make matters worse, the failure typically gives some linking error which doesn't give any hints to the cause of the problem and time is lost troubleshooting it.</p> <p><em>In a project I worked on we started off globbing but got so many complaints when new files were added, that it was enough reason to explicitly list files instead of globbing.</em></p> <p>This also breaks common git work-flows<br>(<code>git bisect</code> and switching between feature branches).</p> <p>So I couldn't recommend this, the problems it causes far outweigh the convenience, when someone can't build your software because of this, they may loose a lot of time to track down the issue or just give up.</p> <p>And another note, Just remembering to touch <code>CMakeLists.txt</code> isn't always enough, with automated builds that use globbing, I had to run <code>cmake</code> before <strong>every build</strong> since files <em>might</em> have been added/removed since last building *.</p> <h2>Exceptions to the rule:</h2> <p>There are times where globbing is preferable:</p> <ul> <li>For setting up a <code>CMakeLists.txt</code> files for existing projects that don't use CMake.<br>Its a fast way to get all the source referenced (once the build system's running - replace globbing with explicit file-lists).</li> <li>When CMake isn't used as the <strong>primary</strong> build-system, if for example you're using a project who aren't using CMake, and you would like to maintain your own build-system for it.</li> <li>For any situation where the file list changes so often that it becomes impractical to maintain. In this case it <em>could</em> be useful, but then you have to accept running <code>cmake</code> to generate build-files <em>every time</em> to get a reliable/correct build <em>(which goes against the intention of CMake - the ability to split configuration from building)</em>.</li> </ul> <hr> <p>* <em>Yes, I could have written a code to compare the tree of files on disk before and after an update, but this is not such a nice workaround and something better left up to the build-system.</em></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload