Cannot do mrbsetenv on OSX with icarus_data
The icarus_data package is, well, a package of various data files... probably it is outdated in the sense that there are meant to be better ways to address the problem it is solving, but it should still be possible to do a setup... As near as I can tell, the problem is that icarus_data itself has no qualifiers AND it doesn't depend on anything. Somehow the following lines in the product_deps file do not get properly parsed on OSX when doing "mrbsetenv":
# We now define allowed qualifiers and the corresponding qualifiers for the depdencies. # Make a table by adding columns before "notes". qualifier notes -nq- the null qualifier matrix end_qualifier_list
I get an obscure bash message telling me that it is expecting more information somehow. If I comment those lines out then I get a different message which is probably generated by cet build tools telling me it can't do the setup because it can't determine the qualifier.
I was able to finally get a temporary workaround by creating an artificial dependence on another package (I picked larbatch which seems harmless enough)... so changing the above lines to
# We now define allowed qualifiers and the corresponding qualifiers for the depdencies. # Make a table by adding columns before "notes". qualifier larbatch notes -nq- -nq- the null qualifier matrix end_qualifier_list
allows mrbsetenv to be happy and I can proceed with the build.
#1 Updated by Lynn Garren over 1 year ago
- Status changed from New to Feedback
mrb 3 is stricter about matching products and qualifiers. This is meant to be a good thing. Are you building icarus_data along with icaruscode or by itself? What packages are in your $MRB_SOURCE directory? We need to be able to reproduce the problem.
One workaround is to explicitly setup mrb v2 until we finish investigating.
#4 Updated by Lynn Garren over 1 year ago
- Assignee deleted (
This is interesting. Within a few minor cleanups, the structure of icarus_data is the same as the structure of larutils. The difference is that icaruscode depends on icarus_data. When building the larsoft product suite, there is no product that depends on larutils and we have no problems with mrbsetenv.
This problem can be reproduced with the instructions below. I have provided a feature branch that reproduces the original problem. It also contains a few minor cleanups.
make a new mrb working directory cd $MRB_SOURCE mrb g icaruscode mrb g icarusutils mrb g icarus_data cd icarus_data git checkout feature/team_investigate_22368 cd $MRB_BUILDDIR (mrb z if necessary) mrbsetenv
#6 Updated by Christopher Green over 1 year ago
- % Done changed from 0 to 100
- Assignee set to Christopher Green
- Status changed from Assigned to Resolved
Despite the workaround being to change the
ups/product_deps file, the actual problem was with the way mrb v3 was reading the
ups/product_deps file, which listed
icarus_data as a dependency.
One of the changes that came with mrb 3 was the ability to specify
-nq- in the third column of a non-
only_for_build dependency's product/version table and omit the column from the qualifier matrix table entirely: the
table_format should be specified on the product/version table's header line thus:
product version <table_format=2>
Unfortunately, when the unqualified dependency was part of the mrb development set, the mrb 2 way of specifying an unqualified non-
only_for_build dependency was broken (if the dependency was found as an installed UPS product everything worked).
So, your choices are:
- Use mrb 2.
- Use mrb 3 >= v3_01_02.
- Change the
ups/product_depsfile as described above and use mrb 3.
Note that in all three of your alternatives above, the existing workaround of having an otherwise-unnecessary qualifier table in
ups/product_deps file is unnecessary and may be removed.