BOOST and pboted

[polistern]

@majestrate raised very important question about the rationality of using BOOST in the project.
The project architecture allows us to replace BOOST with alternatives at this stage.

I prepared small table about used components:

BOOST component	Alternative
program_options	CLI11 (just as example)
filesystem	std::filesystem in C++17 (but then it will be necessary to drop support of old C++ standards)
asio	removed from PacketHandler

Regarding BOOST in parts of libi2pd - these components are not used by the application and have been removed.

I'll post all latest changes soon.

At the moment, I see only one requirement for any BOOST alternatives:
users should not notice any changes and should not be required to make any changes themselves to be compatible with new components.

Decision will be made on the future fate of BOOST in the project after the discussion.

Let me know if anyone has ideas about it.

Thanks

[r4sas]

boost::program_options replacement can be done on std::find: https://stackoverflow.com/a/868894

[majestrate]

getopt is fine if you only do basic cli args as well.

[polistern]

Looks like getopt with getopt_long more suitable in this case.
Just need to think about wrapper for ini config parsing.

I think I'll have time to finish before weekend.

[polistern]

Well, I've done some tests to try different options, and the more I work on replacing program_options, the more it seems like I'm reinventing my own wheel.

Using getopt now looks problematic to me, given that Windows support is planned to be added in the near future.
We may have to add an additional dependency specifically for Windows in this case.

I do not yet discard the option with completely self-written parsing as here.
Just looking around for different options.

What bribes me about CLI11 is that parsing ini file is done just:

app.set_config("-c,--conf")->expected(1, 1);

But even less I want to change one dependency for another (even though this is one hpp file).

@r4sas, @majestrate, what do you guys think about CLI11 library as 2in1 (CLI and INI) parser?

[majestrate]

i do think CLI11 is a very good choice here. we are planning on using it in new codebases at work going forward.

[r4sas]

No problem for me in the current state. In any case, further tests may tell much more.

add: getopt is not a problem for Windows. Build will be done using MSYS2.

[polistern]

Now I'm waiting for CLIUtils/CLI11#789
This change will add backwards compatibility with currently used options like --sam.port

After that, I can start testing CLI11 as part of the pboted.
The current status of CLI11 in the project - better than boost.
Maybe CLI11 stay with the project for a long time, maybe not.
But it will remove last boost dependence.