What would it take to remove boost from XRT?

[newling]

I'm trying to figure out what it might take to remove the boost dependency from the end-to-end IREE AIE compiler stack. As far as I known, XRT is currently the only component which uses boost in the stack.

What's the motivation? At least in my experience, boost is a difficult dependency to manage correctly.

I am opening this issue just to get some idea from the XRT team about what it might take to replace boost with smaller dependencies, STL, and/or our own code. What would be some of the hardest boost components to replace?

Here are the boost headers used, listed with the number of XRT files they're included in:

     57 <boost/algorithm/string.hpp>
      3 <boost/algorithm/string/join.hpp>
      2 <boost/algorithm/string/predicate.hpp>
      5 <boost/algorithm/string/split.hpp>
      1 <boost/algorithm/string/trim.hpp>
      1 <boost/align/aligned_allocator.hpp>
      2 <boost/config/compiler/visualc.hpp>
      2 <boost/foreach.hpp>
     68 <boost/format.hpp>
      1 <boost/lexical_cast.hpp>
      2 <boost/locale.hpp>
      2 <boost/optional.hpp>
      3 <boost/optional/optional.hpp>
      2 <boost/pool/object_pool.hpp>
     42 <boost/program_options.hpp>
      9 <boost/property_tree/ini_parser.hpp>
     49 <boost/property_tree/json_parser.hpp>
     68 <boost/property_tree/ptree.hpp>
      1 <boost/property_tree/ptree_fwd.hpp>
      3 <boost/property_tree/xml_parser.hpp>
      1 <boost/range/adaptor/filtered.hpp>
      1 <boost/range/adaptor/map.hpp>
      1 <boost/range/as_array.hpp>
      3 <boost/range/iterator_range.hpp>
      1 <boost/range/join.hpp>
      1 <boost/stacktrace.hpp>
     28 <boost/test/unit_test.hpp>
      8 <boost/tokenizer.hpp>

I think some of these can easily be replaced with C++ STL:

foreach.hpp
optional.hpp
optional/*
boost/range/*

Maybe some of these can be factored out of the core runtime:

boost/test/*

But for some of these, I don't know what replacement might be used:

stracktrace.hpp 
string algorithms 
property_tree

Has the idea of removing boost from XRT been considered before? Any thoughts/ideas welcome!

[keryell]

I understand your motivation.
But from the bigger picture point of view, this part just™ works™, which is an undeniable quality. :-)
Boost is widely used world-wide and not the worse thing to use or to package.
At the end it might just add to the NIH syndrome which is already a problem.
If you have some spare brain cycles and extra budget, there are other few issues to fix I can see in my priority list: just make it to compile #7806, cleaning up the code (you can dive into https://github.com/Xilinx/XRT/tree/master/src/runtime_src/core/pcie/emulation), improve Vitis and ROCm packaging... :-)
But anyway, just my personal feeling.

[stsoe]

@newling This is work-in-progress. We are removing boost dependencies as we type.

I think we are very close to have no link time dependencies left in the xrt shared libraries, but we have a few inline boost library dependencies some of which can be replaced as we move to use more modern c++. However boost property_tree is the more difficult one. What is the problem with the few inline libraries being used?

As for linking with boost, the stand-alone tools part of XRT do bring in boost library dependencies, but that is not really a problem related to IREE's use of XRT.

[stsoe]

@keryell Your ubuntu23.10 issue is assigned and being fixed now.

[newling]

@stsoe it is good to hear that you're close to having no link time dependencies to boost for the xrt libraries. Header only dependencies are much better (I didn't realize property_tree was header only).

[newling]

@stsoe do you have a rough idea of when XRT will be link time dep free? Weeks/months?

[stsoe]

Hi @newling. I don't see any boost link time dependencies in the shared libraries even today. So this was implemented with the removal of boost::filesystem within the last month or so.

[newling]

Super, thanks Soren.