Build error on systems with boost >= 1.85

[jmickelin]

Description of the bug

This is a followup of sorts to my PR #13609, where a user reported one remaining build issue when using the Boost version supplied by their distro (Arch Linux with boost-1.86 in their case):

[ 86%] Building CXX object src/slic3r/CMakeFiles/libslic3r_gui.dir/GUI/Jobs/NotificationProgressIndicator.cpp.o
/tmp/makepkg/prusa-slicer-git/src/PrusaSlicer/src/slic3r/Config/Version.cpp: In static member function ‘static std::vector<Slic3r::GUI::Config::Index> Slic3r::GUI::Config::Index::load_db()’:
/tmp/makepkg/prusa-slicer-git/src/PrusaSlicer/src/slic3r/Config/Version.cpp:246:51: error: ‘directory_iterator’ is not a member of ‘boost::filesystem’; did you mean ‘directory_entry’?
  246 |         for (auto &dir_entry : boost::filesystem::directory_iterator(cache_dir))
      |                                                   ^~~~~~~~~~~~~~~~~~
      |                                                   directory_entry
/tmp/makepkg/prusa-slicer-git/src/PrusaSlicer/src/slic3r/Config/Version.cpp:259:47: error: ‘directory_iterator’ is not a member of ‘boost::filesystem’; did you mean ‘directory_entry’?
  259 |     for (auto &dir_entry : boost::filesystem::directory_iterator(vendor_dir))
      |                                               ^~~~~~~~~~~~~~~~~~
      |                                               directory_entry

While I -- strangely - could not replicate it myself when rebuilding PrusaSlicer with that version, I did an attempt to chase down why the offending import isn't found in 1.86.

This is my hypothesis:

The symbol boost:filesystem::directory_iterator is declared in boost/filesystem/directory.hpp, but PrusaSlicer's src/slic3r/Config/Version.cpp never explicitly imports it. Instead, it seems to be pulled in transitively by #include <boost/filesystem/operations.hpp>.

However, Boost versions prior to 1.85 only conditionally included it, guarded by a BOOST_FILESYSTEM_NO_DEPRECATED flag. This was removed as part of this commit:

diff --git a/include/boost/filesystem/operations.hpp b/include/boost/filesystem/operations.hpp
index 1c31803fe..034b54fda 100644
--- a/include/boost/filesystem/operations.hpp
+++ b/include/boost/filesystem/operations.hpp
@@ -20,12 +20,6 @@
 #include <boost/filesystem/path.hpp>
 #include <boost/filesystem/file_status.hpp>
 
-#ifndef BOOST_FILESYSTEM_NO_DEPRECATED
-// These includes are left for backward compatibility and should be included directly by users, as needed
-#include <boost/filesystem/exception.hpp>
-#include <boost/filesystem/directory.hpp>
-#endif
-
 #include <boost/detail/bitmask.hpp>
 #include <boost/system/error_code.hpp>
 #include <boost/cstdint.hpp>

So although PrusaSlicer does not appear to have been relying on the deprecated functionality that was removed, it was affected by the includes changing.

It seems wise to just explicitly add this include to PrusaSlicer, as suggested by the comment in the above diff. This should make it compatible with all versions. I will create a PR shortly.

Big thanks to @sl1pkn07 for bringing this to attention. There is also some prior art from the Gentoo build system, where the maintainers appear to have run into the same issue.

Project file & How to reproduce

N/A

Checklist of files included above

• Project file
• Screenshot

Version of PrusaSlicer

2.9.0-rc1

Operating system

Linux: Arch, Gentoo

Printer model

N/A

[SachCZ]

Hello @jmickelin, thank you. It makes sense. Sadly, this is a very unfortunate timing as the window in which the changes could have been merged to the upstream for next release just closed. Especially because it is such an easy fix. It will for sure be part of the release after that.

In the meantime I recommend you patch this wherever needed. Thank you for your time and effort!

[SachCZ]

As you can see, in the end it got squeezed into the release 🍾