Explore splitting out WebEVD as a standalone product
Upgrading this from an email thread with Erica into an issue.
What would it take to make my WebEVD event display a "top level" ups product? Or is there some existing lar* project it fits neatly in?
My goal is for people to be able to use it as easily as
setup webevd, or to develop it with
mrb g webevd.
I assume this would be basically giving it a repository within larsoft on github, and copying the structure of one of the existing ones? What causes it to get build with the rest of the release?
The display currently works with SP DUNE FD and ProtoDUNE. I have ambitions for dual phase, the SBN experiments, and hopefully also DUNE ND.
The code exists in a feature branch of dunetpc at the moment. That location is arbitrary. The pain of checking out and building dunetpc is part of what I want to get away from.
Thanks - Chris
#1 Updated by Lynn Garren about 1 year ago
A quick note here. The product could easily be called webevd. We would build it when making a larsoft distribution, however the larsoft product would not setup webevd. Instead, anyone wanting to use the product would set it up themselves. This will be discussed by the SciSoft team on Monday.
#3 Updated by Lynn Garren about 1 year ago
- Status changed from Assigned to Feedback
- Co-Assignees Christopher Backhouse added
Chris, we suggest a product named webevd. The easiest way forward is for you to develop this initially in your own githup repository. Once it is ready to go, it can be added to the LArSoft github project. Does that work for you?
You will need to be careful about dependencies. You can start with a dependency on larsoft, but I presume that you will only need to depend on one or two of the larsoft products (maybe larrecodnn and larwirecell, but I'm guessing).
The "mrb p webevd" command will generate a skeleton product for you, but please update cetbuildtools to v7_15_01.
#4 Updated by Christopher Backhouse about 1 year ago
I have an initial version of this in the
develop branch at https://github.com/cjbackhouse/webevd . To my surprise it all builds and works, and I managed to figure out how to import my history.
For now I'm taking a dependency on all of larsoft. I figure I can make that more fine-grained later. The ups and build files could probably do with an expert taking a look to tidy things up.
I think the biggest problem is that currently one needs to
setup dunetpc (which I don't declare as a dependency) to build. The reason is that I use
dune/ArtSupport/ArtServiceHelper.h. I don't believe there's anything there that is dune-specific. Seems like it should be moved to some much more fundamental location.
#5 Updated by Christopher Backhouse about 1 year ago
OK, I've resolved the
ArtSupport problem for now by just directly copying the (short) source files I need. We should probably start a conversation with David Adams about a better fix.
The dependencies otherwise all boil down to
lardata and its transitive dependencies, so that ended up fairly simple. If someone could sanity check my github repository I think we're about ready to go.
#7 Updated by Kyle Knoepfel about 1 year ago
Chris, as the WebEVD application really only requires the LArSoft providers, it should be possible to change the dependency from
lardataalg. I understand, however, that easily creating the providers can be a complication. I'd like to suggest some possible solutions. Are you available sometime this week for a Zoom meeting to discuss options?
#8 Updated by Christopher Backhouse about 1 year ago
Yes, I picked lardata just because I have an include of
lardata/DetectorInfoServices/DetectorPropertiesService.h I immediately convert that to the provider in any case, but do I not need the whole thing in order to be able to instantiate the
I'm reasonably available. Please suggest a meeting time.
#9 Updated by Kyle Knoepfel about 1 year ago
Okay, how about 9 am CDT on Friday (4/10)? I'll send out an Exchange invitation if that works.
Regarding service handles: yes, you would need the service system to be able to create one. My argument is that for this application, it is not necessary to create/access a provider through a service handle; it can be done in a different way. We can talk about it in the meeting.
#11 Updated by Kyle Knoepfel about 1 year ago
- % Done changed from 0 to 50
The art developers have met to discuss this, followed by a separate meeting between Chris Backhouse and Kyle. The proposal is:
- In the short-term, modify the
ArtServiceHelperto use a supported (although discouraged) function for now (see https://github.com/cjbackhouse/webevd/pull/1).
- The longer-term solution is that the required providers should become tools that can be dynamically loaded, without involving art's service system. This will require changes in both LArSoft and art, and it will be discussed by the SciSoft team.
#17 Updated by Lynn Garren about 1 year ago
Chris, you can build with c7 on SLF7. Just make this change to ups/product_deps:
diff --git a/ups/product_deps b/ups/product_deps index 7189601..924b803 100644 --- a/ups/product_deps +++ b/ups/product_deps @@ -44,6 +44,8 @@ end_product_list qualifier lardata gallery notes e19:debug e19:debug e19:debug e19:prof e19:prof e19:prof +c7:debug c7:debug c7:debug +c7:prof c7:prof c7:prof end_qualifier_list # Preserve tabs and formatting in emacs and vi / vim:
source .../webevd/ups/setup_for_development -p c7
#18 Updated by Christopher Backhouse about 1 year ago
OK, I just pushed fixes for both issues.
operator<< one puzzles me, since the "wrong" overload should have failed a
static_assert and therefore not been picked. But it's almost certainly the fault of my understanding of SFINAE rather than of clang.