[Clam-devel] Feature request: standard development folder

[Pau Arumi]

Xavier Amatriain wrote:
> Pau Arumi wrote:
>> 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?
> I am not sure what the prefix option is supposed to do (can you explain 
> what is

well in CLAM SConstruct the scons "prefix" option behaves exactly
as the standard unix configure "prefix" option: is the prefix to
the install dirs: prefix/include/ prefix/lib/ prefix/share
prefix/bin
so if you do scons prefix=~/local you'll get clam libs installed
at /home/user/local/lib, etc.

maybe there is confusion with the "install_prefix" option. this
is *not* to be use other than debian packaging. see the scons
--help:

prefix: Install location for CLAM ( /path/to/prefix )
     default: /usr/local
     actual: /home/parumi/local

install_prefix: Install location when packaging (just for .deb
creation) ( /path/to/install_prefix )
     default: .
     actual: .

ok, i'm for changing the second one for something like
debian_packaging_prefix or the like. agree?


> its expected result) but it did not work with me. Does the option modify 
> all the
> SConstructs (not only of CLAM but of the apps?).

of course not. libs and apps are independent. actually we
distribute the sources in separate code tarballs, so we can't
guess its relative location.
that's why the 4 apps have these options. scons --help:


install_prefix: The prefix where the application will be
installed ( /path/to/install_prefix )
     default:
     actual: /home/parumi/local

clam_prefix: The prefix where CLAM was installed (
/path/to/clam_prefix )
     default:
     actual: /home/parumi/local

so when developing you basically need to worry about setting
clam_prefix (so it matches the clam "prefix" options), and you
probably don't need to install apps.

> In any case, it is not exactly equivalent for a number of reasons. The 
> main one
> is that I am asking for a check point (or warning) at compile time. I am 
> also asking

i guess these checks had to do with the previous
prefix/install_prefix confusion. or you still seeing some checks
to do? in this case please explain.

> for a special flag that overrides whatever you have put into your 
> install_path and clam_path.

forget about install_path (we'll change its name). now, it seems
clear to me that using a single option (clam_path) is better than
using two options (clam_path, devel). moreover it's the standard
way.

> The prefix option on configuration time may work but what if you then 
> specify a different install_path?
> How does prefix and the Scons flags interact? It may not be possible but 

prefix actually is a scons flag. i don't understand the question
but i guess now it's all clear.

> what I'd like is a "devel" flag
> that overrides whatever might have gone into your scons cache and 
> replaces it with a fixed path (relative
> to your sandbox, of course) so you don't need to worry about mixing up 
> that stuff.
> 
> As for the LD_LIBRARY_PATH issue, I agree that is tougher to solve. If 
> you have clam libraries and
> headers in standard system directories you are doomed. But again I could 
> imagine that having a compile time
> flag like "devel" should help in banning Scons from going into those 
> folders... but I might be just dreaming :)

there are two different problems which we should address
separately:
1. loading the wrong libs at *run time* and
2. linking against the wrong libs  at *linking time*.

LD_LIBRARY_PATH is only related with "run time" when you execute
a clam app. so it have absolutely nothing to do with scons
options. so i really don't see a way (other than document it) to
prevent the danger of using system clamlibs when the developer
forgets to set LD_LIBRARY_PATH.

about linking time: in theory this should be fixable. it's about
instructing scons (and ultimately g++) to not to use the system
paths (/usr/local/lib, /usr/local/include)
i'm gonna do some experiment on this. but let me ask david again,
maybe he knows already. david??
but note that having an extra (devel) flag is of no use at all
here. a clam_prefix is all we need

hope that clarifies the issue

pau

btw, testfarm logs shows how to compile all clam binaries using
non-system locations:
http://clam.iua.upf.edu/testfarm/details-linux_ubuntu_feisty-2007-04-26-19-31-49.html