Bug #10735

missing UPS entry for libwda

Added by Kevin Retzke almost 5 years ago. Updated almost 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Spent time:
Occurs In:


From Jason St.john( RITM0298852):


I'm trying to make use of the lab's Web Data Access API in lardata/Utilities/DatabaseUtil.h, but get a compilation error if I do
#include <wdh.h>

The error is "No such file or directory."

Here I'm setting up
uboonecode v04_29_00 -q e9:prof
and working from develop.

The UPS product for WDA is set up:
$ printenv | grep WDA
SETUP_LIBWDA=libwda v2_22_0 -f Linux64bit+2.6-2.12 -z /grid/fermiapp/products/larsoft

But I can only get compilation to work when I additionally set this:
export LIBWDA_INC=/grid/fermiapp/products/larsoft/libwda/v2_22_0/Linux64bit+2.6-2.12/include

Maybe the UPS package isn't set up just right?

CMakeLists.txt (2.27 KB) CMakeLists.txt Kevin Retzke, 11/02/2015 02:59 PM


#1 Updated by Lynn Garren almost 5 years ago

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

It is true that libwda does not define LIBWDA_INC. The recommended solution is to add the following line to your CMakeLists.txt file.

include_directories( $ENV{LIBWDA_FQ_DIR}/include )

We will make sure LIBWDA_INC is defined in future releases, but please edit your CMakeLists.txt file for now.

#2 Updated by Kevin Retzke almost 5 years ago

reply from:

I don't seem to have any success with just inserting the line

include_directories( $ENV{LIBWDA_FQ_DIR}/include )

near the end of lardata/CMakeLists.txt. It's attached to this email.
What's wrong here?

#3 Updated by Lynn Garren almost 5 years ago

My apologies, I thought that you were working with your own code, not with lardata itself.

lardata does not use libwda. larevt, however depends on libwda and already has the required cmake infrastructure.

I strongly suggest that you talk to either Erica or Gianluca. Your code most likely does not belong in lardata.

#4 Updated by Jason St. John almost 5 years ago

After speaking with Gianluca I am trying to move the uboone-specific code to the uboonecode repo.

The first step is to see if I can

#include <wda.h>

in source code there. I'm using uboonecode/uboone/Database/ and I get the same build failure:

fatal error: wda.h: No such file or directory

Mirroring the CMakeLists.txt of larevt, where this #include works,

In uboonecode/CMakeLists.txt, add among the other find_ups_product() directives:

find_ups_product( libwda v2_21_0 )

In uboonecode/uboone/CMakeLists.txt I don't see anything I need to do 
In uboonecode/uboone/Database/CMakeLists.txt, I add in the art_make():
...and at the top of the file, add these two lines:

include_directories( $ENV{LIBWDA_FQ_DIR}/include )

.... Nope. Compilation fails.  
But it works when I do this:

export LIBWDA_INC=/grid/fermiapp/products/larsoft/libwda/v2_22_0/Linux64bit+2.6-2.12/include
mrb i --generator ninja

SO it still looks to me as though setup libwda is failing to set this environment variable.

#5 Updated by Lynn Garren almost 5 years ago

ups products are required to define the _VERSION and _DIR variables. Although most also define _INC and _LIB, that is not presently required. We can add LIBWDA_INC to the next release of libwda, but you can use the existing product as is.

In larevt, I find:
include_directories( $ENV{LIBWDA_FQ_DIR}/include )

However, libwda is also explicitly listed in the ups/product_deps file. That may be the piece you are missing.

#6 Updated by Jason St. John almost 5 years ago

Thanks, Lynn. I also added this line to the uboonecode/ups/product_deps file:
libwda v2_22_0

Re-built, same failure. Zapped, logged out, logged in, and re-built. Same failure.
I tried again with
libwda v2_21_0
along with unsetup libwda and then setup libwda v2_21_0. No improvement. (But then, LIBWDA_INC isn't set with this version, either.)

The only thing which makes this work is explicitly setting LIBWDA_INC.

Thanks for your attention to this. When my feature branch is ready to merge into uboonecode develop, I don't want to be asking to explicitly some environment variable just to compile. That's what the mrb/ups interaction is for!

#7 Updated by Lynn Garren almost 5 years ago

Jason, is your code on a feature branch? I'd like to try to reproduce your problem.

#8 Updated by Jason St. John almost 5 years ago

Hi, Lynn,

Check out feature/stjohn_dbwebproxy.

#9 Updated by Lynn Garren almost 5 years ago

I have pushed the necessary change to feature/stjohn_dbwebproxy. Once I added the following directive to uboone/RawData/utils/CMakeLists.txt, everything was fine.

include_directories( $ENV{LIBWDA_FQ_DIR}/include )

Note that you do NOT need find_ups_product(libwda ...) or libwda in ups/product_deps. Also note that if you add a product to the list in product_deps, you also need to add it to the product matrix.

The include_directories line is also found in uboone/Database/CMakeLists.txt, but that does not affect the build in uboone/RawData. MicroBooNE may wish to move the include_directories line to the top CMakeLists.txt file so the header can be found wherever needed.

#10 Updated by Lynn Garren almost 5 years ago

The changes in feature/stjohn_dbwebproxy have solved the build problem.

However, since there is a new release of libwda ready, the next release of nutools and larsoft (both scheduled for this week) will include a libwda that defines LIBWDA_INC.

#11 Updated by Lynn Garren almost 5 years ago

libwda v2_22_1 is now built and available. This release defines LIBWDA_INC as expected. libwda v2_22_1 is part of the nutools v1_17_00 distribution and will be part of the larsoft v04_30_00 distribution.

#12 Updated by Lynn Garren almost 5 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

#13 Updated by Lynn Garren almost 5 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF