Revise the build setup for user-defined modules (MyModule) about nest-simulator HOT 11 CLOSED

See also #213.

from nest-simulator.

With #213, modules can be build statically, dynamically or as plug-in ( Install mechanism) - also on BlueGene. But you still get an error, when the module is linked dynamically and you load it again with an Install.

I have not tried it yet, but there is a possibility, to have cmake build sub-cmake-projects just by adding it as a subdirectory (here).

from nest-simulator.

@jougs @heplesser @apeyser
Dynamic loading of external user modules is the only reason NEST depends on libltdl. This leads to inconveniences, if the library is not present by default, e.g. on JUQUEEN, see this comment in #390. Further dynamic loading increases the code / project complexity:

• The DynamicLoaderModule is responsible for locating, loading and maintaining the modules.
• The script extras/nest-config.in must be filled correctly with compiler information, flags, include directories, linked libraries, s.t. the user module builds correctly.
• The user module has to initialize correctly. It can be build dynamically or statically. If build dynamically, it can be loaded dynamically by Install() or linked directly into NEST. If build statically, it must be linked directly into nest. The initialisation is different in every case:
  • Dynamic / Install() MyModule has to create a global instance named mymodule_LTX_mod. The libltdl will look for this instance in a dynamic loaded module when calling Install('mymodule'). Then the DynamicLoaderModule will call init() in this instance and the module is loaded.
  • Dynamic / direct MyModule has to create a global instance. In the constructor it registers itself with the DynamicLoaderModule. In neststartup() the DynamicLoaderModule initializes all registered modules with initLinkedModules().
  • Static cmake generates a file static_modules.h with cmake/WriteStaticModules_h.cmake. This file contains the function add_static_modules(), which is called in neststartup(). In the function each static module (along with the basic modules of NEST, i.e. models, precise, topology and conngen) is added to the sli engine and thus initialized. In this case no global instance of the module is necessary (and might be harmful, if state is shared among instances of the same module).

Also linking a user module directly into NEST requires to build NEST alone, so that nest-config is build correctly, required link libraries are available and the install directory is laid out. Then the module can be build and installed (into <prefix>/lib/nest). Finally, NEST has to be reconfigured, adding -Dexternal-modules=my to the cmake line, build and installed.

Possible solutions to simplify the situation (of which I can think of):

1. Only allowing direct linking (static or dynamic) is not desirable, as one still has to compile NEST twice. This anyway was more a 'emergency solution' to enable user modules for environments that only allow static compilation, e.g. earlier BlueGene systems (please correct me if I am wrong).
2. Only allow the Dynamic / Install() strategy: This would simplify the DynamicLoaderModule (no registered modules), MyModule (has to build only as dynamic module), cmake/WriteStaticModules_h.cmake does not have to consider external modules and users do not have to compile NEST twice. But nest-config is still required and NEST still has the dependency with libltdl if user modules are used.
3. Rewrite the user module system to use cmake's add_subdirectory() functionality. An example for this is the conngen module:

   • For a new module create a new folder inside of NEST's sources, e.g. mkdir mymodule.

   • Create a simple CMakeLists.txt similar to conngen's, which only defines the sources the library target, the linking, includes and install instructions.

   • Write the module code and the new models, functions, etc inside this folder.

   • In the main CMakeLists.txt file have a section that conditionally adds subdirectories that are defined on the cmake line, e.g.: ... -Dexternal-modules=mymodule ...

     foreach ( mod ${external-modules} )
       add_subdirectory( "$mod" )
     endforeach()

   • In nest/CMakeLists.txt add the library target of the external module to the call target_link_libraries( nest ... ) and target_link_libraries( nest_lib ... ).
     The initialization can also be reduced to one strategy: either by dropping the DynamicLoaderModule registration (and removing the loader completely) and only rely on static_modules.h, or remove the static_modules.h creation and register all modules (also NEST's defaults) with the DynamicLoaderModule. (Looking at #271 it would also be possible to have two loaders: one for NEST only modules with no link to the SLIInterpreter and one for SLI modules that register new functions and dictionaries or names with the SLIInterpreter.) This approach removes the dependancy with libltdl completely, makes nest-config obsolete, reduces the initialization strategies to only one and reduces the overall complexity. The downside is that one has to have access to the sources, which might be difficult if NEST is emploied in prebuild binaries, e.g. as homebrew or APT packages.

from nest-simulator.

@tammoippen Thank you for the analysis! I think the next step should be an in-depth analysis of possible use cases (extending your very last remarks above), before we decide on a solution.

from nest-simulator.

@tammoippen 3 is just another way to do 1?

from nest-simulator.

Would 2 still link the standard modules that come with NEST statically? If yes, I like that most.

from nest-simulator.

@apeyser Yes, except that you do not have to compile twice and do not have to hassle with nest-config.

@jougs Yes, the standard modules will be linked directly (if static or dynamic depends on whether you build NEST statically or dynamically).

from nest-simulator.

@apeyser, @heplesser, @jougs - what needs to happen for this issue to be closed?

from nest-simulator.

@heplesser @abigailm

I believe we'd have to come to a decision on what dynamic module capabilities to offer re: tammo's analysis, and then actually do it.

I'm not sure who's offering the programmer time for this, now that Tammo is gone.

from nest-simulator.

@abigailm @apeyser I'll take responsibility for this one.

from nest-simulator.

Closing this one as the issue has not been pressing for the last two years.

from nest-simulator.