Switching to boost filesystem? about libosmium

[DennisOSRM]

• Leave things as they are. After all it works and there are no extra external dependencies.

Has the benefit of trading an external dependency for maintainability.

• Switch to Boost Filesystem. Makes some code cleanups possible. Introduces external dependency. But C++ standard "File System TS" will be very similar to Boost Filesystem, so change later should be very easy.

Boost.Filesystem is very easy to work with. It is used all over the place in OSRM. Unfortunately, there is no light-weight header-only variant of it.

Wait for C++ "File System TS", which is in the works and will probably released sometime this year. It might take a while to get implemented everywhere though.

Sounds like option 1 with the later possibility of switching. 😀

Would it make sense to go with option 1 (or 3) and encapsulate the platform-dependent code into a separate header file?

[alex85k]

ШI am not an expert. Boost filesystem is good and easy enough, but to encourage usage of Osmium it is better to have fewer dependencies that are small and easy to build/install. OSRM is a big-executable project for running mainly on server, so extra dependency and 500kb does not matter. Osmium-based utilities are smaller.

So I would separate the platform-dependent code and use ifdefs for now, and later switch to option 3.

I would even consider redistributing already needed part of boost together with libosmium :)

[DennisOSRM]

Right, OSRM already uses boost in plenty of places. It didn't introduce another dependency.

[springmeyer]

few ifdefs seem fine, but of any boost dependencies I found filesystem quite manageable. In Mapnik we've kept most of the usage hidden from headers in case we need to switch it out for some platform: https://github.com/mapnik/mapnik/blob/master/src/fs.cpp

[joto]

Thanks for all your comments. I'll keep things as they are for the time being. There aren't that many filesystem interactions and any attempt to factor out some code or use the boost filesystem library would probably make the code worse instead of better.

Looking at the Mapnik code that @springmeyer linked to, I have to ask myself why I want a library that is specifically made to hide operating system differences when every call to that library has to be wrapped with another function that is compiled differently depening on the OS.