Andreas Schuh wrote: > How often have you seen CMake code as the following > > add_executable(foo foo.cpp) > > ?
I see executables with a single source file only in dummy test code, and even then add_executable(foo main.cpp) is more common. > > The basis_add_executable supports this use case as well, but additionally > the shorter notation (not counting the basis_ prefix ;) ) > > basis_add_executable(foo.cpp) Yes, that's what I was referring to. I see why you have it. I'm not convinced it should be upstreamed. > is intended to bridge both, make the use of > globbing expressions convenient and safe at the same time. I would like to see investigation into what can be done upstream to benefit cmake users who do not use BASIS. >> Another example: You have code for adding scripts as executables. What >> are the generic (non-BASIS related) use cases for that? >> > You can define dependencies among them or to modules written in the same > scripting language. Can you say why this is useful? Is it only useful in cases where the buildsystem creates a particular/modified script from an input, such as by replacing @VAR@? > You can have find_package calls to find installed > modules and declare that your script depends on them. Why is this useful? If my script depends on something external I require the find_package. Can you be more specific on what BASIS does in addition here? > An installation rule > for the script may ensure that the modules get installed as well. I can imagine that defining, say, a python library as such for packaging and installation purposes could be generically useful, but I'm not sure that that is what you are saying. I'm trying to find descriptions of things in BASIS that should be in cmake, that show gaps in cmake functionality etc. > When > wrapping scripts in Windows Command files to mimic the she-bang directive > of Unix, calling such script becomes just as convenient as it is on Unix > from the command line without having to specify the interpreter executable > explicitly. I'm not familiar with Windows, but this comment doesn't seem to relate to cmake? > >> >> Should CMake be extended with similar capabilities somehow? >> >> I personally believe this could be very useful to quite a few users. >> >> Would it help if an IMPORTED executable could be a script? >> >> What would this entail? Is there perhaps another question behind this >> question? > Instead of relying on the actual name of the installed > executable file, the build target is imported and any external executables > are only called by their assigned build target name. Yes. >> 2) Do you generally recommend that CMake users use BASIS from now on, or >> is it something you expect will be niche/mostly used by yourselves? >> > > The first and foremost target group are clearly research groups Yes. > and less > experienced software developers or those who do not want to bother writing > a considerable amount of CMake code rather than their actual software. I'm not personally convinced your approach is the best one, but it's not aimed at me anyway. I'm only interested in finding upstreamable features and concepts, and finding gaps in the cmake offering. >> 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. >> > Initially I started off overriding the original CMake commands Yeah, don't do that... :) > On a side note, just today a co-worker asked me why the compiler cannot > find the header files when they were provided as additional arguments to > the add_executable command. Indeed this was a reasonable assumption, I > think. Why the need for an additional include_directories when I already > specified where the header files are located ? This is not something BASIS > is taking care of yet either, but would certainly be one of the things I > would consider adding. This is the kind of concrete feedback *about cmake* that I'm looking for in this discussion. It's self contained, refers to existing cmake functionality, it's easy to imagine the 'user story' and what the user code would look like etc. I don't have any comment about the viability of adding such functionality to cmake add_* commands though. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
