Project

General

Profile

Bug #5448

mrb slp is not setting up

Added by Jonathan Asaadi about 6 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
02/14/2014
Due date:
% Done:

0%

Estimated time:
Occurs In:
Experiment:
MicroBooNE
Co-Assignees:
Duration:

Description

So the issue here is a weird error I get when trying to resume work on a previous nightly release that I have created earlier.

What I've done is create a nightly build test release, checked out larreco, created a new branch, edited code, complied and ran. All this worked fine.

Now I login to a new shell and execute the following commands in this order:

source /grid/fermiapp/uboone/software/setup_uboone.sh
setup uboonecode nightly -q e4:prof
setup ubtools
cd /uboone/app/users/jasaadi/NewRelease_git_mrb/
source localProducts_larsoft_nightly_e4_prof/setup
cd build/
source mrb slp

and her I get this error:
local product directory is /uboone/app/users/jasaadi/NewRelease_git_mrb/localProducts_larsoft_nightly_e4_prof
----------- check this block for errors -----------------------
ERROR: Version conflict -- dependency tree requires versions conflicting with current setup of product larsim: version v1_00_02 vs nightly
----------------------------------------------------------------

Now Eric gave me a workaround that if I run the command

source mrb s
source mrb slp

this error goes away and all is fine....but this doesn't seem like this is expected behaviour and might point to a problem with mrb slp...so I wanted to point it out.

Thanks

History

#1 Updated by Lynn Garren about 6 years ago

  • Status changed from New to Assigned
  • Assignee set to Lynn Garren

What you have seen is an important feature of the system. By design, the build system checks to make sure you have a consistent set of packages. This is because not using a consistent set can lead to subtle bugs and inconsistent results that are very hard to track.

Because you have a local build of larreco, this complicates the setup. The suggested workaround is the best way to proceed for now when using nightly.

It is our expectation that users will most often work against tagged releases and NOT against some nightly build. There will be frequent tagged releases - perhaps once a week. This is a change in working procedure that we think is important. Fully blessed releases will be much less frequent, but you should, by default, be building against a tagged release unless you have an explicit need to work with the nightly build.

#2 Updated by Lynn Garren about 5 years ago

  • Status changed from Assigned to Resolved

#3 Updated by Lynn Garren about 5 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF