Reddit C++ – CMake for Small Projects?
Here&#x27;s my experience.  This is partly a CMake rant and partly a CLion rant, but I feel like the issues&#x2F;confusion with CLion are a reflection of the issues with CMake.<p>I&#x27;ve been struggling for months to convert my hobby project from Code::Blocks to CMake (so I can use CLion IDE).<p>What I was trying to do should be simple:  I want my subdirectories to build as static libraries, and then link them all with a main.cpp at the top level.<p>First obstacle:  CLion has (or had) no documentation on how to do this, and no project wizard to create an example project with this structure.  No support for a &quot;workspace&#x2F;solution&quot; with multiple &quot;projects&quot; like Code::Blocks or Visual Studio.  CLion (appeared to) require one IDE instance per &quot;project&quot;.  At that point, why even use an IDE?  And how do I link my executable project to my library project(s)?  Might as well use a text editor and terminal, if I have to alt-tab to switch between projects and have no help managing dependencies between projects.<p>Eventually I realize that, although CLion is one instance per (top-level) &quot;project&quot;, that doesn&#x27;t mean you can&#x27;t have other <i>CMake</i> projects <i>if</i> they are in subdirectories.  However, once again the CLion docs are no help in setting this up, and the CMake docs are really confusing.<p>One of my in-tree 3rd party dependency libraries has its own well-written but very old CMake build scripts.  For another of my in-tree dependencies I cobbled together a set of CMake scripts by combining ones someone had written for the different version of the library together with I-don&#x27;t-understand-this-but-it-seems-to-work duct tape programming.  Cargo cult programming comes to build scripts.<p>Of course, I was still using manual paths to the cmake-build directory to get the linking to work, and I knew this wasn&#x27;t right.  In Visual Studio, I can just &quot;Add Reference&quot; from one project to another project, where was this option in CLion &#x2F; CMake?<p>It was at this point I got seriously led astray by trusting bloggers writing about &quot;Modern CMake&quot;.  Yes, the new CMake imperatives of the form &quot;target_foo(...)&quot; (replacing just &quot;foo(...)&quot;) <i>are</i> an obvious improvement.  That&#x27;s not what I&#x27;m talking about.  The trap for the newbie is that many&#x2F;most of these blog posts exhort you to structure your libraries as CMake packages.<p>&quot;Look!  You can build a static library, shared library, or even a .deb file from these!  You don&#x27;t have to write a FindFoo script, CMake find_package will know how to find your libraries!&quot;<p>Cue super-complicated (for a CMake newbie, compared to what I actually needed) set of incantations to make your project subdirectories into CMake packages.  (Still subtly broken because Modern CMake is a moving target which moved on since the example was created.)<p>So I wasted a good several months trying to convert my large codebase to this format.  Never could get my CMake scripts working reliably.  Remember the third party in-tree dependencies full of legacy CMake code and my own cargo cult duct tape?  I&#x27;d be hard-pressed to separately understand either these or how CMake package config should work.  I definitely couldn&#x27;t keep both of these in my head at the same time.<p>Finally I realized:  this is stupid.  I&#x27;m <i>not</i> authoring Debian packages; my sub-libraries are only used by this project, not exported.  I <i>can&#x27;t</i> link system-installed alternate versions of my open-source library dependencies (they&#x27;re not compatible - that&#x27;s why the right version is in-tree).  And I shouldn&#x27;t have to &quot;make install&quot; subdirectories of my own source tree before I build the executable (the only thing which uses them). I just want to Build All from the source tree.<p>I realized that all that following &quot;the Right Way&quot; to do CMake had accomplished for me was to replace hard-coding linker paths with hard-coding a &quot;find_package&quot; hint path.<p>Once I realized I was wrong about the Right Way, and after having studied CMake for a long time without really grokking it, I realized the answer had been in front of my face:  just use &quot;add_subdirectory()&quot; to add each of my static-library subdirectories &#x2F; subprojects (instead of all the CMake package mumbo-jumbo).<p>My point being (and the relevance of this comment to the linked Reddit thread) is that it turned out there was a simple way to do a simple thing, but it needs to be better called-out, both that it exists and when&#x2F;why you might want to use it.  The problem is that there&#x27;s not a good on-ramp to the learning curve that starts with &quot;here&#x27;s simple ways to do simple things&quot;.  Instead (when you Google for help) it comes back a mix of really basic and really advanced things and (much like git) you have to already know what you&#x27;re looking for in order to find it.