[CMake] Announcing CMake BASIS, a set of CMake based project interoperability and automation tools

[Andrew Hundt]

On Thu, Jan 23, 2014 at 4:14 AM, Stephen Kelly <steveire at gmail.com> wrote:

> Andrew Hundt wrote:
> > I'm not well versed with the guts of git but are there any good
> > ways to do some cleanup?
>
> If you have to ask, the details probably not something worth discussing
> here. Adding a commit removing them is not going to help. My previous paste
> showed that some of the biggest files are already deleted in the current
> tree.
>

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.

>    - Automated packaging and installation of libraries
>
> 'Automated' is also an awkward and almost meaningless word. It would not
> surprise me to be told that 'cpack provides automatic packaging of
> libraries' and that 'cmake provides automatic installation of libraries'.
>
> Are you referring to the fact that your basis_* commands do more than those
> cmake commands which have similar names? If the names were more-
> significantly different, would it still be 'automatic'?
>

If you follow the Quick Start
Guide<http://opensource.andreasschuh.com/cmake-basis/quickstart.html>
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 "make
package_source<http://opensource.andreasschuh.com/cmake-basis/howto/package.html#distribution-of-sources>"
will each produce a reasonable result. This specific automation requires
considerably fewer steps and boilerplate code than the equivalent pure
CMake code would.

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.

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?



> >    - basis_add_doc()
> >    - Support for doxygen documentation of CMake Code
> >    - built in support of documentation tools
>
> 'built-in' is also awkward. If it was not 'built-in', what would it be?


> So far, out of what you listed, the documentation related stuff is most
> interesting to me as an upstream trying to find upstreamable (or generally
> useful) stuff in BASIS, or trying to find the gaps in cmake which are
> suitable for closing in cmake itself.
>

 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.

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.

> 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.
>
> I wasn't aware that that was difficult with cpack alone. I'm not overly
> familiar with cpack, but it could be somewhere that the situation can be
> better.
>

I also would see tighter integration between CMake and CPack as a good
thing.


>> Should CMake be extended with similar capabilities somehow?
> >
> > I personally believe this could be very useful to quite a few users.
>
> What form would such a change in cmake take? What would a user write, and
> why - what use-case to it satisfy?
>
> >> Would it help if an IMPORTED executable could be a script?
> >
> > What would this entail? Is there perhaps another question behind this
> > question?
>
> The question behind the question is 'how should a user of cmake define a
> "script target", and why?'.
>

I believe Andreas answers this question and the one above pretty well in
another post in this thread, so I defer to him.


>> 3) BASIS requires me to use basis_add_executable, KDE4 requires me to use
> >> kde4_add_executable, VTK requires me to use vtk_add_executable.
>
> >> my point is that
> >> wrappers are not good API proxies.
> >>
> >> Any comments on that?
> >>
> >
> > Cool, is there a good reference explaining how wrapped functions can be
> > eliminated?
>
> What do you mean by 'a good reference'. If you're looking for a particular
> targetted document, then no, there is not.
>

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.

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.


> >> 4) BASIS seems to expect settings, flags etc to be written as directory
> >> scoped. Modern CMake is increasingly scoped to targets, with directory
> >> scoped commands considered only convenience for populating properties on
> >> targets.
> >>
> >>
> >>
> http://www.cmake.org/cmake/help/git-master/manual/cmake-buildsystem.7.html#directory-scoped-commands
> >>
> >> This is mostly helpful for transitive usage requirements and related
> >> CMake concepts.
> >>
> >> Do you think BASIS would move in a similar direction?
> >>
> >
> > 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.
>
>  http://www.cmake.org/cmake/help/git-master/manual/cmake-packages.7.html
>
> http://www.cmake.org/cmake/help/git-master/manual/cmake-buildsystem.7.html


How does one browse to these sphinx docs from the cmake website? I've never
come across them before and I generally use the main cmake
docs<http://www.cmake.org/cmake/help/documentation.html>
.

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. :-)


>
>
>  http://www.kdab.com/modern-cmake-with-qt-and-boost/
>
> Thanks,
>
> Steve.
>

Thanks for the extra links.

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.

Cheers!
Andrew Hundt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20140127/14c94c61/attachment-0001.html>