Kurt and Marc notes¶
Where does one start?
- Make ups tools available [Kurt does this in login, usually]
- Setup the art product he wants to use [after looking at what’s available]
- Make a directory for source code.
- User’s guide should have recommended directory structure: Kurt prefers product name as top-level directory (as in art)
- A tool to make the directory structure would be nice; shouldn’t know about CVS/SVN/git
- Tool should add boilerplate to make necessary things (exes, tests, dynamic libraries, static libraries are also needed)
- Tool should fill out contents of the ups directory (at least as a starting point; include some dummy dependency)
- Tool should write a setup_for_development
- Prefer the generated cruft to be example/template to work from rather than a working system that builds some bogus code that is also written by the tool.
- The tool should make CMakeList.txt files in the created directories, with example libraries, tests, etc.
- The table.in file and associated cruft should be generated
- Purpose of cet_cmake_env(KurtProduct ...) is unclear
- Different version of canned dependence on cetbuildtools version was not obvious. Why is a minimum required version there? Why is any version required? Why is an exact version not required?
setup_for_development is not easy to edit; global replace of product name seemed obvious.
Modifying product_list to include dependencies on underlying product needs documentation: what does “-q +$CETPKG_QUAL$extraqual” really mean?
setup_for_development returns 0 even on failure; hard to tell that it failed.
When trying to compile first compilation unit, got a failure: ‘Unknown CMake command “cet_make”’; forgot to write “include (CetMake)” in the CMakeLists.txt
The copied x.table.in file is very verbose. The tool should generate something as simple as possible (but not simpler!) This file is complex, and the non-expert user may well be overwhelmed by it.
The “faking out unsetup” comments are alarming. This is the most confusing part of the system so far. We were lucky in that the copied file was accidentally OK, including the dependency on fhicl-cpp.
In the CMakeLists.txt in the source directory, we had to add transitive dependencies for the products used by the product we’re using. This is icky.
How do we find what version of fhicl-cpp the version of art we set up depends upon (including the qualifiers used)?
It was not clear that find_ups_product() was needed in the top-level CMakeLists.txt file, when find_library() was needed in the lower-level CMakeLists.txt file (this was to find fhiclcpp). Needing to specify both seems redundant. A simple typo in a product name (extraneous underscore) lead to an inscrutable error message (about a symbol FHICLCPP being undefined). A better message would be nice; an addition to a FAQ would be OK.
BUILDING our first executable:
Used artdaq/DAQrate/CMakeLists.txt as an example to find the command to build an installable exe.
Trial-and-error to find all the necessary additions to the CMakeLists.txt to actually find the headers, and then to link to the right things.
Again, the error message that comes from a wrong find_library() call is misleading. We put the library as ‘art’, not ‘art_Framework_Core’. and the complaint was the symbol ART was undefined, not that no ‘libart.so’ was found.
The amount of “boilerplate” dependencies necessary to use “art” is large (many root libraries, especially). It would be good to have this reduced.
SRT has arch_spec_boost.mk, etc., include “umbrella” files that include a bunch of products.
A call that says “include art and everything it needs” would be good.
- If there were a single CMake macro that marked an executable for building and installing, that might help.
I prompted Kurt to run “buildtool -h”, which gave instructions. It was obvious where the installed files went.
To test an installed product, one has to go into a new shell and try using it. Is there a way to make this easier?Some things that would help are (KB):
- something to create the stubs that are needed to make a new package
- instructions that describe the functions that can (and should) be included the CMakeLists.txt files
- CMakeLists.txt fragments that handle a full set of functions for us (for example, if we could "include (EverythingNeededForArt)" instead of guessing the 30+ lines that are needed, that would be great)