Project

General

Profile

Support #15852

Remove cmakedefine from gallery?

Added by Corey Adams over 3 years ago. Updated 3 months ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
03/13/2017
Due date:
% Done:

0%

Estimated time:
Scope:
Internal
Experiment:
MicroBooNE
SSI Package:
Duration:

Description

Gallery is pretty darn nice. It's a good tool to work with files without having a huge dependency stack. But, it'd be really really nice to be able to build gallery on a laptop and use it on larsoft files for analysis prototyping and quicker things. The reasons:

1) Gallery is still 4gb to download, and the number of supported systems (though growing) will never cover everyone. Building ups products for gallery is not 100% simple, though the build scripts make things a little easier.

2) Using ups to use gallery locks you in to python and gcc that ups comes with. I understand this is essential to assure proper linking and behavior running on grid nodes and in production, etc. But it's not a practical requirement if an analyzer wants to make a quick analysis on data products on their laptop. When using gallery on a laptop, this also prohibits you from using any python tools you have installed since you must use ups python.

3) The time from a fresh start to working in gallery is pretty long a laptop: you have to either download or build ups, which takes awhile. It's complicated to get students started doing this.

So, I want to be able to build gallery using system python and system gcc (or whatever python and gcc, essentially). I don't know how to trick ups into thinking that my system python is the one it has installed (I tried, but didn't 100% succeed, and it was not a nice solution). So instead I tried to build gallery and it's dependencies without using ups. I had no trouble getting the dependencies like boost, etc, through my system. I am trying to make a successful build system for these tools without modifying source code, but I'm finding that there are files and c++ code that are cmake-dependent.

I understand that cmake is the official build system for these products. But it would be really useful to be able build this code without cmake, using custom makefiles. I think this would be really useful for microboone students, so I hope you can help me address these questions:

Is it possible to structure these repositories without *.in files? And without #cmakedefine statements? Without these, I can build and link everything in gallery with pretty simply build scripts.

If it's not possible to have no *.in files and remove #cmakedefine statements, can you help me find a workaround to process these files and build with standard makefiles? I don't work with cmake and I don't want to make modifications to these repositories when I pull them. So, I prefer the first option, but a script that can handle these preprocessor directives would work too. I can write this but I need guidance.

Thanks!
Corey

generate-file (1.18 KB) generate-file Marc Paterno, 04/21/2017 03:26 PM

History

#1 Updated by Corey Adams over 3 years ago

Well, it's been awhile with no response. Does anyone monitor these tickets? I will open tickets elsewhere too.

Thanks,
Corey

#2 Updated by Marc Paterno over 3 years ago

  • Status changed from New to Feedback

We have put this issue into feedback status, pending the meeting arranged to talk with Corey.

#3 Updated by Marc Paterno over 3 years ago

The use of #cmakedefine in gallery is involved with the solution to a somewhat thorny problem. The issue is that some C++ libraries we use define std::cbegin and std::cend, while others do not. We need to be able to write a header that will provide an implementation of both, but only if the C++ library being used (not the compiler being run, which might be ROOT's JIT compiler when the header is read) does not provide these function templates.

To solve this problem we use CMake's try_compile feature to determine whether the C++ library being used supplies the functions. The cetconfig.h.in file in question is then used to create the correct header, based on whether the try_compile succeeded or failed. Since we're building with CMake, we have used a convenient tool provided with CMake to do the processing.

We have attached to this issue a file containing a bash script generate-file that provides an ability similar to the CMake tool that we use for processing the *.in file. However, the alternative build system that uses this script still will need to replace CMake's try_compile functionality with something else to whether the compilation of the code using std::cbegin and std::cend was successful.

Rather than solve the specific problem of the one place where we currently use #cmakedefine, this script will take any file which makes use of same and turn it into another file where the specified uses of #cmakedefine have been resolved, as follows:

Usage: generate-file <in-file> <out-file> <var>=0|1...

So, in order to resolve the current issue, one would invoke:

./generate-file <src-path>/cetconfig.h.in <dest-path>/cetconfig.h CET_HAVE_STD_CBEGIN_CEND=x

where x is non-zero where cetlib/cetlib/conf/test-cbegin.cc compiled and linked correctly, and zero where it did not.

#4 Updated by Corey Adams over 3 years ago

Hi,

Thanks for getting back on this. With Microboone's collaboration meeting this week, I won't have time to give this a try until next week at the soonest. I just wanted to say thanks for doing this and I will give it a try as soon as I can next week.

Corey

#5 Updated by Kyle Knoepfel over 1 year ago

Corey, this issue has been open for awhile. Is there still something here that needs addressing, or can it be closed?

#6 Updated by Kyle Knoepfel 3 months ago

  • Status changed from Feedback to Closed

Closed due to no more feedback.



Also available in: Atom PDF