Closed EinarElen closed 2 years ago
I've started playing with updating the Menu
class to auto-load menu lines at library linking time. I'm not sure if this would be helpful for you, but the changes to Menu and test_menu.cxx are on the auto-load-menu branch
I've made some progress on the auto-loading procedure and I think it is ready for broader use. The test_menu file on the auto-load-menu branch shows how to use the newer functionalities of Menu
. The registration of menu lines with the central menu is done at library linking time since declare
calls are within anonymous namespaces. You can separate the declare
s (and therefore the functions) across any number of files as long as they are compiled with (or linked to) the final executable. This removes the need for a RunMenu
function which constructs the menu and the need for a header file sharing the function declarations between the executable and the implementation files.
updated it to use boost-python-like syntax for registration of menu lines, e.g.
namespace {
auto sb = Menu<int>()
.line("ONE", "one command", one_command_func)
.line("TWO","another command", another_command_func)
;
}
This looks really useful. I can't really test it out with this issue yet though since it doesn't compile with pftool
For now, something morally equivalent to https://github.com/LDMX-Software/pflib/tree/iss56 seems works for this
In principle, just having the tasks menu separated out works for me. However, if it would be useful I could do something similar for the other top-level menus that aren't super small already
The pftool.cc file is getting so large that developing anything in it if you aren't already completely familiar with every line of code is prohibitive. When working on the tasks menu, I've been ripping out the related functions into a separate translation unit and added a header file for pftool (pftool.h). This works fine for me in isolation, and in principle I can just keep merging things into my setup and reinserting anything we want to keep into a separate branch, the time required to do so for me is much less than the additional time it takes to develop stuff inside one big file, but obviously I'd rather work in the same world as everyone else.
I'm just moving the tasks part, but if anyone wants to separate out anything else to a distinct translation unit then doing so in the same manner should be trivial.