Add Boost to ET

Issue #1775 new
Erik Schnetter created an issue

There was a request to support Boost in the ET. I suggest to add our Boost thorn, in the same way that we currently support PETSc.

Keyword:

Comments (9)

  1. Frank Löffler
    • removed comment

    Boost is a large library, and often is split into smaller packages. Which of these do you suggest to require if the thorn is given as requirement by another thorn? These would need to be tested for existence and usability by the thorn, and should be given as suggested packages for common OSs.

  2. Erik Schnetter reporter
    • removed comment

    For a thorn called Boost, I want all of them. If you want only one of them, you should use a thorn Boost_Serialize.

  3. Frank Löffler
    • removed comment

    How do you check for an installed version then? Testing just one feature isn't likely to get you the full picture. Boost can (and is often) split up into several packages. I do have some of them installed, but don't have others, for example. Would the thorn Boost still build a full version of Boost, even though thorns might be happy with the library that is already installed? Should thorns then depend on what they actually need, something like Boost_Serialize instead of the full Boost?

    If going that way, the logic would be something like this: Detect all existing Boost components (that Cactus cares about), see if any required components are missing, build the full Boost in that case (or just that component if easy and possible).

    How could we do this using the existing build mechanism? This doesn't sound easy, or I am missing something.

  4. Zach Etienne

    I really dislike dependency bloat, as it adds more possible points of failure during compilation and slow compilations greatly. (I’m cringing at the thought of compiling Boost in serial…) Returning to Frank’s question: What parts of Boost are needed? Can we just use those?

  5. Erik Schnetter reporter

    In CarpetX, we are using some algorithms for non-linear root-finding in con2prim. However, they don’t work on GPUs, and we might want to re-implement them anyway for this reason.

    I think that RePrimAnd also uses Boost, probably for filesystem operations (?).

  6. Wolfgang Kastaun

    Reprimand uses boost only internally for root-solving (con2prim) and ODE-solving (TOV solver). Both will not be replaced any time soon but those are header-only dependencies that could be distributed with reprimand. Include files exported by reprimand do not include anything from boost so this wont lead to clashes with other code doing the same. The only file operations use hdf5, nothing from boost.

  7. Roland Haas

    If and when we include Boost in the ET I would strongly advertise to include the whole thing, i.e.there is one “Boost” thorn that provides everything. Splitting up Boost into Boost_FileSyste and Boost_SpecialFunctions etc similar to what eg Debian’s package manger does, just buys into lots of dependency issues.

    To me the goal of ExternalLibraries is to provide a simple, working fallback and way to for Cactus thorns to interface with the 3rd party libs. It should not become a full featured package management system since we lack resources to maintain that. If this means it is slow the relying on fallback compilation, then so be it. If it is slow all the time even when mostly not used (OpenSSL is in that category if it compiles) then this may be an issue.

    Generally I feel that expecting a 5minute compile time, without any prior experience and expecting a fully optimized build that way is not realistic for a scientific code. I certain level of experience of the user is expected, at least if they desire an “optimized” build.

  8. tootle

    For my 2cents, I think it is an excellent idea to add a thorn that can detect boost libraries, but I think having to include the ability to build the whole library is too much bloat not to mention compile time. The number of dependencies that boost has in order to build the full suite is incredibly large - run spack concretize for a full boost spec and you’ll see what I mean. Even on our cluster, boost alone can take 30+ minutes to compile the full suite including dependencies.

    I understand this goes against the ETK paradigm of everything that is needed is included, which should definitely be the case for fundamental components such as Carpet (glad to hear CarpetX will remove the boost dependency), but I think it would be more useful to fail gracefully and list the Thorns that depend on boost rather than defaulting to building the entire suite. Also, for modern clusters boost is usually available by default, but the environments may not be updated correctly making automated searches like those in Radice’s boost not robust. Cmake has incredibly good features for finding boost as well as individual components, but this still depends on the environment correctly setting `BOOST_ROOT`.

  9. Log in to comment