<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 22, 2014 at 5:44 PM, Stephen Kelly <span dir="ltr"><<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Andrew Hundt wrote:<br>
<br>
> CMake BASIS is a set of utilities and standards created with the goal of<br>
> making CMake projects and libraries very easy to create, share, and reuse.<br>
<br>
</div>Hello,<br>
<br>
There seems to be several years of development behind this already. Is it<br>
newly public, or newly publicized? I've never heard of it before.<br></blockquote><div><br></div><div>The <a href="http://opensource.andreasschuh.com/cmake-basis/about.html">about page</a> and the <a href="https://github.com/schuhschuh/cmake-basis/releases/tag/v3.0.0">3.0 release on github</a> explains the history reasonably well. Previously it was public but not publicized. For the v3.0 release we moved it to github, redesigned and rewrote much of the documentation, added custom project templates, and made everything else configurable. For example we needed take out previously hard coded items such as University of Pennsylvania logo (I'm at Carnegie Mellon).</div>


<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> Website: <a href="http://opensource.andreasschuh.com/cmake-basis/index.html" target="_blank">http://opensource.andreasschuh.com/cmake-basis/index.html</a><br>
> GitHub: <a href="https://github.com/schuhschuh/cmake-basis/" target="_blank">https://github.com/schuhschuh/cmake-basis/</a><br>
<br>
</div>The repo is surprisingly large (67 mb) for something like this. I consider<br>
such large files in a git repo to be bad practice. This is just the first<br>
thing I noticed...<br>
<br>
Commit: [...]</blockquote><div><br></div><div>Hmm, I hadn't noticed the size before. There are a few powerpoint presentations and a PDF manual that probably contribute to the size, there are also a couple of small external libraries that are directly committed into the tree. The zip version of the release is 2.7 MB which is not quite as bad. I'm not well versed with the guts of git but are there any good ways to do some cleanup?</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
> Also, if any CMake developers are interested in bringing any of this<br>
> functionality upstream into CMake itself we would also love to hear from<br>
> you.<br>
<br>
</div>I read some of the docs and some of the code (TargetTools.cmake). My<br>
understanding my not be complete or correct.<br>
<br>
1) BASIS seems to be doing lots of things. Can you identify what parts of<br>
BASIS or what concepts are most valuable/most useful/most missing from CMake<br>
etc? I think you could know better than we can.<br></blockquote><div><br></div><div>I would suggest many of the items from the <a href="http://opensource.andreasschuh.com/cmake-basis/apidoc/modules.html">BASIS CMake modules</a>, specifically the section labeled "BASIS Modules".</div>

<div><br></div><div>Some of the specific useful items include:</div><div><ul><li><a href="http://opensource.andreasschuh.com/cmake-basis/apidoc/latest/group__CMakeAPI.html#ga06f94c5d122393ad4e371f73a0803cfa">basis_add_doc</a>() - built in support of documentation tools</li>

<li>Additional support for other languages, such as MATLAB and Python</li><li>Automated packaging and installation of libraries</li><li>Support for doxygen documentation of CMake Code</li></ul></div><div>I'm sure there is more but those are some of the most obvious items that I can think of off the top of my head.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For example, do you consider<br>
<br>
 add_executable(myexe.cpp)<br>
<br>
to be good user interface for creating a target called 'myexe', and<br>
something that CMake should do? </blockquote><div><br></div><div>It seems like it would be pretty straightforward and easy to use. I've seen that functionality implemented independently on more than one occasion.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Should CMake automatically create<br>
installation rules for it?<br></blockquote><div><br></div><div>I think this would be excellent if there was a reasonable default, plus more advanced configuration for when it is needed. This could also happen for libraries. Right now it seems CMake has a lot of boilerplate that could be skipped by making functions automate steps using reasonable defaults that can be modified or disabled as needed.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Another example: You have some target-source-file-globbing code. Should that<br>
be extracted, generalized and upstreamed?<br>
<br>
 <a href="https://www.mail-archive.com/cmake-developers@cmake.org/msg06725.html" target="_blank">https://www.mail-archive.com/cmake-developers@cmake.org/msg06725.html</a></blockquote><div><br></div><div>I've seen a number of requests for such funcitonality so it may be desirable, although I don't personally use it.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another example: You have code for adding scripts as executables. What are<br>
the generic (non-BASIS related) use cases for that? </blockquote><div><br></div><div>Many projects aren't libraries or installable software for distribution in one language, but instead a set of custom utilities that call each other via the general Unix philosophy. Also, groups that build embedded software or backend software will have scripts that automatically start, monitor, deploy, implement, and/or run their software. Programs based on scripting languages also need packaging and installation just like any other compiled language if they are to be opened via an icon on a user's system.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Should CMake be extended with similar capabilities somehow? </blockquote><div><br></div><div>I personally believe this could be very useful to quite a few users.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Would it help if an IMPORTED executable could be a script?<br></blockquote><div><br></div><div>What would this entail? Is there perhaps another question behind this question?</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another example: Can the documentation utilities be separated from the rest<br>
of BASIS, made generic and still be useful?<br></blockquote><div><br></div><div>Yes, I believe that is possible. I may be mistaken but I believe DocTools.cmake is fairly independent aside from a few auxillary files in the local folder that it configures.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) Do you generally recommend that CMake users use BASIS from now on, or is<br>
it something you expect will be niche/mostly used by yourselves?<br></blockquote><div><br></div><div>Everyone will have different use cases and needs, and BASIS doesn't handle 100% of CMake functionality. However, I personally expect that I will use BASIS on my own projects because it simply cuts out a lot of the manual steps and boilerplate needed for documentation and setting up a typical project/library directory.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3) BASIS requires me to use basis_add_executable, KDE4 requires me to use<br>
kde4_add_executable, VTK requires me to use vtk_add_executable.<br>
<br>
BASIS seems to wrap many or most CMake commands which define the<br>
buildsystem. That was realized to be bad practice in KDE. The new KDE<br>
Frameworks (KF5) do not have that requirement or practice, and instead the<br>
regular add_executable CMake commands (and similar) are recommended. CMake<br>
has been extended (by myself and others) to make that possible without<br>
losing features. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This way, not only is interoperability increased, but users of a KF5 package<br>
can rely on the CMake documentation to understand and reason about code they<br>
read and write. Further, the buildsystem for KF5 is CMake not 'something on<br>
top of CMake', which then must be understood. Using CMake directly, and not<br>
'something on top of CMake' is also a goal of the boost effort to migrate to<br>
CMake.<br>
<br>
Further, wrappers like that can not cleanly offer all of the features of<br>
wrapped commands, as those commands get updated in CMake. I'm not sure your<br>
wrappers can handle ALIAS, INTERFACE or OBJECT libraries for example, and it<br>
seems that<br>
<br>
 add_library(tgt SHARED IMPORTED)<br>
<br>
might work, whereas<br>
<br>
 add_library(tgt IMPORTED SHARED)<br>
<br>
would not. Ok, it's not documented to work either, but my point is that<br>
wrappers are not good API proxies.<br>
<br>
Any comments on that?<br></blockquote><div><br></div><div>Cool, is there a good reference explaining how wrapped functions can be eliminated? Some of the functionality like the automated packaging steps are made possible by the wrapped functions, but if there was another way to do it I'm sure that would be ideal.<br>

</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
4) BASIS seems to expect settings, flags etc to be written as directory<br>
scoped. Modern CMake is increasingly scoped to targets, with directory<br>
scoped commands considered only convenience for populating properties on<br>
targets.<br>
<br>
 <a href="http://www.cmake.org/cmake/help/git-master/manual/cmake-buildsystem.7.html#directory-scoped-commands" target="_blank">http://www.cmake.org/cmake/help/git-master/manual/cmake-buildsystem.7.html#directory-scoped-commands</a><br>



<br>
This is mostly helpful for transitive usage requirements and related CMake<br>
concepts.<br>
<br>
Do you think BASIS would move in a similar direction?<br></blockquote><div><br></div><div>Yes, I would expect it to follow the direction of CMake. As a side note, one thing I've wished for with CMake is an up-to-date style guide, how-to, and tutorials capturing the best recommended way to write Modern CMake code for a cross platform distributable library. For example, even the <a href="http://cmake.org/cmake/help/cmake_tutorial.html">basic cmake tutorial</a> doesn't use the more recent "Modern CMake" capabilities.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Thanks,<br>
<br>
Steve.</blockquote><div> </div><div>Thanks for all your feedback and interest! It is appreciated.</div></div></div></div>