Default location of generated module .so file

[Silmathoron]

Currently (at least for my nest install), the path for modules is supposed to be given by export NEST_MODULE_PATH=$NEST_INSTALL_DIR/lib/nest in nest_vars.sh.
This is also where NESTML installs the modules.

However, unless it's been added to the library path, this directory is not accessible by default, contrary to $NEST_INSTALL_DIR/lib (which has to be otherwise NEST doesn't run, obviously).

Thus, I think one of the following is necessary:

• explicitly state in the documentation that this path needs to be added
• install to $NEST_INSTALL_DIR/lib, just forbidding the following the following names

    libmodels
    libnest
    libnestkernel
    libnestutil
    libprecise
    librandom
    libsli
    libsli_readline
    libspatialindex
    libspatialindex_c
    libtopology

The only issue I see with this, is that if people install NEST to ~/.local, the is a (very small) possibility the might overwrite an existing .so file and break something (though it would not be critical).
I would say it's worth the risk, but you might have a different opinion ^^

[jougs]

@Silmathoron: I like your second suggestion a lot. It makes things more consistent, requires less documentation and in nest/nest-simulator#1071 I even remove the export of $NEST_INSTALL_DIR/lib/nest from nst_vars.sh as I found the pollution of the environment more confusing than helpful. @clinssen what do you think?

[jougs]

Also, some of the reserved names mentioned in the list above will go away when nest/nest-simulator#1182 is fixed.

[clinssen]

I agree with the above, that is to install the generated .so files into lib/ instead of lib/nest/, so that the location is the same as other NEST shared objects.

Naming conflicts are not an issue, as we already force module names to end in "module", a suffix that is not contained in any of the other NEST shared object filenames.

[clinssen]

Oops! I missed the fact that existing, non-NEST .so files could still be overwritten. In general it seems that naming conventions are relied upon so that this situation never happens. So, we could force the inclusion of "nest" or "nestml" in the module filename to avoid conflicts.

Or, we could continue to generate in lib/nest, but document this issue and add it to default library paths wherever possible. I noticed that this is also where the MyModule example gets installed to by default, even though there is it also not mentioned in the documentation.

[Silmathoron]

I would be in favor of the first solution and discuss at a NEST VC about stopping the use of lib/nest entirely

[clinssen]

After discussion with @jougs, we consider it in bad style to place generated .so files into lib directly, as it may accidently overwrite other files (apparently there was a naming conflict with an Infiniband library named libtopology.so in the past, conflicting with the NEST shared object by the same name).

Other libraries (see ls /usr/lib) seem to prefer to create their own subdirectories. This means that we would have one subdirectory called nest. Instead of changing the location of the user modules from lib/nest to lib, we should change the location of all NEST .so files to lib/nest!

I will create a new issue/PR about this soon on the nest-simulator repository. This means that on the NESTML side, nothing has to be done, so I am closing the issue.