<div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><div dir="ltr"><div>On Thu, Jan 23, 2014 at 4:14 AM, Stephen Kelly <span dir="ltr"><<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>Andrew Hundt wrote:<br></div><div>> I'm not well versed with the guts of git but are there any good<br>> ways to do some cleanup?<br><br></div>If you have to ask, the details probably not something worth discussing<br>
here. Adding a commit removing them is not going to help. My previous paste<br>showed that some of the biggest files are already deleted in the current<br>tree.<br></blockquote><div><br></div></div><div>The level of my question my have been underestimated, because I was referring to git commands that strip data from the history. I created an issue to take another look at the size, thanks for the feedback.</div>
<div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> - Automated packaging and installation of libraries<br>
<br>'Automated' is also an awkward and almost meaningless word. It would not<br>surprise me to be told that 'cpack provides automatic packaging of<br>libraries' and that 'cmake provides automatic installation of libraries'.<br>
<br>Are you referring to the fact that your basis_* commands do more than those<br>cmake commands which have similar names? If the names were more-<br>significantly different, would it still be 'automatic'?<br></blockquote>
<div><br></div></div><div>If you follow the <a href="http://opensource.andreasschuh.com/cmake-basis/quickstart.html" target="_blank">Quick Start Guide</a> and create a simple library and executable you will notice that with only a call to basis_add_library() or basis_add_executable() commands to "make package", "make install", and "<a href="http://opensource.andreasschuh.com/cmake-basis/howto/package.html#distribution-of-sources" target="_blank">make package_source</a>" will each produce a reasonable result. This specific automation requires considerably fewer steps and boilerplate code than the equivalent pure CMake code would.</div>
<div><br></div><div>My experience has been that people use CMake because they want to spend less time dealing with a build system and strange syntax, and CMake is great at being cross platform, has an easy to read language, and takes out lots of the work by supporting many frequently used libraries with find_package. I think that removing even more steps can only be a good thing.</div>
<div><br></div><div>I have some flexible first thoughts on how integrating it could work, but others such as you would have much more experience in the matter. I recognize that it may not be possible to simply change CMake's add_library call to work like the BASIS version. There must be some useful way that similar functionality could be brought upstream so perhaps CMake policy flags for newer versions, storing the information in target properties, or entirely new functions?</div>
<div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> - basis_add_doc()<br>
> - Support for doxygen documentation of CMake Code<br><div>> - built in support of documentation tools<br><br></div>'built-in' is also awkward. If it was not 'built-in', what would it be?</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>So far, out of what you listed, the documentation related stuff is most<br>
interesting to me as an upstream trying to find upstreamable (or generally<br>useful) stuff in BASIS, or trying to find the gaps in cmake which are<br>suitable for closing in cmake itself.<br></blockquote><div><br></div>
</div>
<div>Great, I too believe the basis_add_doc(), basis_add_doxygen_doc(), and basis_add_sphinx_doc() functions and related files would be perfect candidates to put in the "Modules" folder of CMake itself after whatever other minor tweaks are necessary.</div>
<div><br></div><div>I also have a script that is not in BASIS that makes it easier to write a find script for basic libraries, I'll start a separate thread for that.</div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>> Programs based on scripting<br>> languages also need packaging and installation just like any other<br>> compiled language if they are to be opened via an icon on a user's system.<br><br></div>I wasn't aware that that was difficult with cpack alone. I'm not overly<br>
familiar with cpack, but it could be somewhere that the situation can be<br>better.<br></blockquote><div><br></div></div><div>I also would see tighter integration between CMake and CPack as a good thing. </div><div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>>> Should CMake be extended with similar capabilities somehow?<br>
><br>> I personally believe this could be very useful to quite a few users.<br><br></div>What form would such a change in cmake take? What would a user write, and<br>why - what use-case to it satisfy?<br><div><br>>> Would it help if an IMPORTED executable could be a script?<br>
><br>> What would this entail? Is there perhaps another question behind this<br>> question?<br><br></div>The question behind the question is 'how should a user of cmake define a<br>"script target", and why?'.<br>
</blockquote><div><br></div></div><div>I believe Andreas answers this question and the one above pretty well in another post in this thread, so I defer to him.</div><div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>>> 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></div><div>>> my point is that<br>>> wrappers are not good API proxies.<br>
>><br>>> Any comments on that?<br>>><br>><br>> Cool, is there a good reference explaining how wrapped functions can be<br>> eliminated?<br><br></div>What do you mean by 'a good reference'. If you're looking for a particular<br>
targetted document, then no, there is not.<br></blockquote><div><br></div></div><div>Allow me to rephrase, could you send a link or other reference such as a summary posted on a mailing list where I can learn about the KDE situation and how it was resolved? Essentially, I would appreciate any additional information you could give me that would help me apply your experience to my own project.</div>
<div><br></div><div>However, I suspect the reasons, design, purpose, and goal of kde4_add_executable and basis_add_executable may have been significantly different but I would like to learn more.</div><div><div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>>> 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>>><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<br>>> CMake concepts.<br>>><br>>> Do you think BASIS would move in a similar direction?<br>>><br>><br>> Yes, I would expect it to follow the direction of CMake. As a side note,<br>
> one thing I've wished for with CMake is an up-to-date style guide, how-to,<br>> and tutorials capturing the best recommended way to write Modern CMake<br>> code for a cross platform distributable library.<br>
<br></div> <a href="http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html" target="_blank">http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html</a><br> <a href="http://www.cmake.org/cmake/help/git-master/manual/cmake-buildsystem.7.html" target="_blank">http://www.cmake.org/cmake/help/git-master/manual/cmake-buildsystem.7.html</a></blockquote>
<div><br></div></div><div>How does one browse to these sphinx docs from the cmake website? I've never come across them before and I generally use the <a href="http://www.cmake.org/cmake/help/documentation.html" target="_blank">main cmake docs</a>.</div>
<div><br></div><div>May I also suggest the idea of switching to the readable-wide theme BASIS uses for your sphinx doc instead of the original python doc layout? I didn't create it but I have found it is very clean and easy on the eyes. :-)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br><br> <a href="http://www.kdab.com/modern-cmake-with-qt-and-boost/" target="_blank">http://www.kdab.com/modern-cmake-with-qt-and-boost/</a><br>
<div><br>Thanks,<br><br>Steve.</div></blockquote><div><br></div><div>Thanks for the extra links. </div><div><br></div><div>One specific CMake functionality that isn't in BASIS that I've thought would be useful in CMake would be a set of modules that are the super build equivalent of find scripts. <br>
</div><div><br></div><div>Cheers!</div><span><font color="#888888">Andrew Hundt</font></span></div><div><span><font color="#888888"><br></font></span></div></div></div></div></div>