<div dir="ltr"><div class="gmail_extra">On Wed, Oct 25, 2017 at 10:36 AM, Carlton Banks <span dir="ltr"><<a href="mailto:noflaco@gmail.com" target="_blank">noflaco@gmail.com</a>></span> wrote:<br></div><div class="gmail_extra"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is there some literature that desbribes how cmakelist has to be defined a big system, that involve multiple smaller modules within the big module.</blockquote><div> </div></div><div class="gmail_extra">Unfortunately, written documentation of structuring larger projects with CMake seems to be as rare and hard to find as documentation on CMake "Best practices". I suspect that the individual uniqueness of each large project combined with "once it is working don't touch it" means that developers settle on something that "works" rather than something they are happy with, and so don't show it off.</div><div class="gmail_extra"><br></div><div class="gmail_extra">If you have anything beyond a fixed repository of code with simple dependencies then you seem to be pretty much on your own.</div><div class="gmail_extra"><br></div><div class="gmail_extra">As a start, I'd suggest looking for other large projects that transitioned to using CMake - I've found LLVM useful in particular as a large but tightly-bound set of modular, but optional components. KDE is using CMake, but I've yet to find a good place to start digging - the ecosystem is so intimidatingly large that I'm not sure their solutions are applicable to anyone else except them. Hopefully Boost will move to CMake (as is currently proposed) and give another well known library example.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Nick</div></div>