Let me paraphrase what I understood:<br>
----------------------------------------------------<br>
In singleton.cpp you are going to declare<br>
Log Log::info<br>
CLI CLI::singleton<br>
ProgramDoc ProgramDoc::singleton<br>
<br>
Then the PROGRAM_INFO macro would refer to ProgramDoc::singleton directly<br>
or indirectly.<br>
-------------------------------------------------<br>
<br>
There is no guarantee that ProgramDoc::singleton would have been created<br>
before the macro which must represent an object is created. Why can't we<br>
just move PROGRAM_INFO et al. inside main. Then we can make sure that<br>
CLI::singleton is created after Log::Info and ilk. I am not sure of the<br>
ramifications though.<br>
<br>
I came into CLI_Deleter because I wanted to build a mlpack.lib-free<br>
executable. I removed `#include "cli.hpp"` from core.hpp and managed to run<br>
a simple CNN trainer (basically the mnist test) on Raspberry Pi without<br>
compiling the mlpack library. I just added log and prefixedoutstream cpp<br>
files.<br>
<br>
My suggestion is to move CLI away from core and include it explicitly in<br>
all the applications. This will help better adoption of mlpack.<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Fri, Feb 26, 2016 at 12:40 PM, Ryan Curtin <notifications@github.com><br>
wrote:<br>
<br>
> There is... one other possibility. This could be appealing if the idea of<br>
> getting all of the classes associated with CLI or mlpack inside of<br>
> libmlpack.so, and it's also appealing from a code size reduction<br>
> standpoint. (I think this also means that if you just #include<br>
> <mlpack/core.hpp> without using anything in it, you don't need to link<br>
> against -lmlpack.)<br>
><br>
> The idea is to make ProgramDoc a singleton of its own, then make the<br>
> PROGRAM_INFO() macro a call to access the ProgramDoc singleton and set its<br>
> parameters. The ProgramDoc singleton can then be put into some file like<br>
> src/mlpack/core/util/singletons.cpp which can also contain the CLI and<br>
> Log objects (technically the Log objects aren't singletons, they're global<br>
> variables, but hey, I couldn't think of a better name for it...). Then we<br>
> can control the order of construction (and thus destruction) and can<br>
> eliminate the need for CLIDeleter entirely.<br>
><br>
> What do you think? Maybe there is something I have overlooked?<br>
><br>
> Thanks for looking into this, by the way. The CLI module hasn't gotten<br>
> much attention since it was written in 2011. :)<br>
><br>
> —<br>
> Reply to this email directly or view it on GitHub<br>
> <https://github.com/mlpack/mlpack/pull/524#issuecomment-189073562>.<br>
><br>
<br>
<br>
<br>
-- <br>
Joseph Chakravarti Mariadassou<br>
http://thesundayprogrammer.com<br>
<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>Reply to this email directly or <a href="https://github.com/mlpack/mlpack/pull/524#issuecomment-189141898">view it on GitHub</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AJ4bFJTWLaVnHT3-GQJADX1B0rANzNGUks5pn_DqgaJpZM4HiVT8.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
<link itemprop="url" href="https://github.com/mlpack/mlpack/pull/524#issuecomment-189141898"></link>
<meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>