Re: [Nemiver-list] some questions

[Dodji <dodji domain hid>]

Hello Gordon,

> 1. Is it possible to "make" and test nemiver, without doing a complete
> "make install" ?

You have to install the relevant dynamic modules you modified. For
instance, if you changed something in src/gdbengine, you have to:
sudo make -C src/gdbengine install .

This will install only stuff that are in src/gdbengine. It is faster
than installing everything.

> It seems the main program tries to load library modules and it always
> looks in "/usr/lib"...

Yes, pretty much each component in nemiver is a dynmod (dynamic
module). A dynmod is a a module that can be loaded from the dynmod
load patch. It has a description that is an xml file. Dynmod
descriptions are in $prefix/lib/nemiver/config .
For instance the dynmod gdbengine (the debugger engine) has a
description file named gdbengine.conf . The dynmod description file
says where to load the dynmod from, and what is the name of the actual
shared library that contains the dynmod code.
This is why dynmods actually have to be properly installed so that the
dynmod loader can find them.
Dynmods actually have some nice traits. They allow a proper separation
between interfaces and implementation. Client code use the interface
but are not linked with the actual implementation. The dynmod loader
loads it explicitely on demand at runtime. That means actual
implementations can be changed *after* installation. The only
requirement is that those implementation comply with the API. This is
how we can expect nemiver to support backends other than GDB in the
future, or to support configuration managers other than gconf etc ...

> if I "make" nemiver in the source directory and try to execute
> "./src/nemiver", the old modules are still loaded from "/usr/lib",
> instead of my new and updated modules in the local directory.

I dont'  know if it would be really worth it to add a debugging mode
to the dynmod loader to make it scan $pwd to find dynmods, instead of
looking into the information provided by the dynmod configuration
file, located in $prefix/lib/nemiver/config . But if you find it could
really worth it, then we can seriously think about it. The code to
deal with dynmods is in src/common/nmv-dynamic-module.cc . The main
function that loads a dynmod is DynamicModule::Loader::load (const
UString &a_name) ;
The function that returns the path where to load the dynmod from is:
DynamicModule::Loader::module_library_path (const UString &a_module_name);

I am not really sure if that is really worth it, instead of just make
install *only* the dynmod you changed.

>
> Same thing happens for "xml" files - there are
> "get_absolute_resource_path" functions that insist on loading the "xml"
> files from "/usr/lib/nemiver/plugins/...." instead of the local directory.

Yes, that is quite normal and is not really tied to nemiver. The xml
files you are talking about are the glade files, I think. Those are
really to be loaded from a specified path, and trying to load them
from local directory could be quite complicated. When installed, those
files endup at the same place, more or less. So it is easy to know
where to look them from. When under $top_srcdir those can be scattered
accross several subdirs, and looking for them can be quite erroprone
... while a simple sudo make -C src/foo/blah install could install
only a small amount of things and yet get you going safely.

>
> So every time I change something and want to test it, and have to "su"
> and "make install" - quite time consuming...

Yeah, I understand your problem. Maybe trying "sudo make -C
src/what/you/changed/dir install"  Could help.

-- 
Dodji Seketeli
http://www.seketeli.org/dodji