Cet build-packaging work - day one notes¶
Adam mentioned he has a ups-product working dir that has a top level CMakeLists.txt
file. There is a way (not revealed yet) to automatically generated this.
Chris wants "this" to guarantee consistent builds.
Gennadiy - uboonedaq - structure is not yet decided -- between one repo and 3 products
and one repo and one product.
Discussion about how source code system "tagging" of product(s) effects this decision.
Working through logistics for actual work...
rsync of whole products dir vs. building a new one from tarballs.
/opttypes of users (in priority (Jim's) order for this retreat):
- members of experiments/project
- "build manager" for experiment/project
- somebody starting a new project
Chris doesn't like people who do rsyncs.
Starting point for "what to do" is cetbuildtools User Guide
gmed getRedmineGit gn2aretexamples # "add package"
similar to SRT newrell and addpkg
Needs to source ../..../setupfordevelopment
What about multiple "setupfordevelopments"???
Discussion about whether or not this can be automated.
Discussion about the new setup
B option... it does not cause an error status to be returned.
Chris mentioned that there is an issue with tcsh.
The following may be interesting:
$ tcsh [root@firstvm /etc]# echo `false` [root@firstvm /etc]# echo $status 1 [root@firstvm /etc]# echo `true` [root@firstvm /etc]# echo $status 0
and in bash:
$ echo `false` $ echo $? 0 $ echo `true` $ echo $? 0
Start work on "Use cases" CET_build_and_packaging_system_working_session¶
Discussion on "products_list"
Wisdom from of old is that all products upon which a product depends on should
be listed. Do not rely on sub-products to setup products which your product directly
depends on. There may no be a fool-proof way to automatically generate the list of
products which your product directly depends upon, but regardless, the attempt to list
your direct depends should still happen.
Discussion about indicating a change in (direct) dependencies.
The wisdom from old was that this did require a version change but the version
change would be in the form of either a "subminor" number change (ie. v1_2_03 to v1_2_04)
or the appending of a letter to the version number (i.e. v1_2_03 to v1_2_03a).
The meaning of the various (major/minor/subminor) numbers or characters in a version "number"
should be documented.
Another possible way to indicate changes in dependencies is through qualifiers, which also
would be documented.
Note that, as the dependencies are saved in the source, the changing of dependencies, is, in
a way, a change to the "source".
Discussion of setup -B...
ups needs to return a non-zero error status upon error....
This can be done by writing the appropriate statements in the to-be-sourced
The non-zero status can distinguish between different errors: ie. dependence conflict or