[Clam-devel] Feature request: standard development folder

[Pau Arumi]

Xavier Amatriain wrote:
> Every time I get CLAM going in development mode in a new computer I
> suffer from severe stress ;) And it is because of stupid things like
> paths that are not set properly or libraries that are loaded from the
> wrong folder (e.g. I wasn't able to fix a bug because  I did not realize
> that every time I was running Network Editor it was loading the default
> libraries in /usr/local/lib, not the ones I was compiling in my
> development directory).
> 
> I was thinking that a way to minimize this problem would be to define a
> standard location for deploying CLAM libs when in devel mode (something
> like /trunk/CLAM/libs). We could make it in such a way that when sending
> scons the -devel flag it would automatically set that as the install
> path. And we could also be very explicit in the instructions (even
> issuing a message when the flag is active):

what you describe is exactly equivalent of using the prefix
option. this is how david and me work, and i think that it's also
well explained in the INSTALL. don't you agree?

http://iua-share.upf.edu/svn/clam/trunk/CLAM/INSTALL
"
  To install clam in a non system-wide place (usefull when 
developing) use
  scons configure with these options: (you must create the 
destination dir before)

	$ scons configure prefix=~/local

  Then export LD_LIBRARY_PATH=~/local/lib before running the apps 
with these libs.
  (Probably you also want to add this export line into your .bashrc)
"

however, there is a weak point on this (or having a fixed devel
prefix as you suggested): when linking, scons always add the
-L/usr/lib path (or g++ always look there, i'm not sure), so
having installed clam libs is bad for developing.
i don't know if this can be worked around. ideas, david?

> Of course there is the trick I just learned today from David, which is
> putting all the processings you are working on out of CLAM and into the
> NetworkEditor, but I don't think that should be the recommended way of
> working.

this trick is only useful when adding *new* processings. i think
it's not bad at all because it simplifies the compile process.
and when the new processing is mature enough it can be moved into
the clam lib.

in the future (near future i hope) we'll have processings plugins
libs. this will enable users to create their own plugins which
NetworkEditor will load without having to compile clamlibs nor
NetworkEditor.


pau