On 11-04-12 07:07, Julia Lawall wrote:
On Tue, 10 Apr 2012, Jim Cromie wrote:
the distro version on fedora is working, as is Nicolas Palix's package
for ubuntu.
The "apparent" difference is PCRE support, though that doesnt seem
very pertinent.
Did one come from a fedora package and the other from us? If so, I guess
it is a standard problem - the coccinelle build process can't know where
other packages with the same name have been installed. On the other hand
if both versions came from us, then maybe it is because a lot of things
have changed in the make file. Arie will have to look into it, but he
may be travelling today.
It's a bit of a long email, but I hope that it contains answers to the
other questions.
About the installation locations:
The installation procedure adheres to the standards for GNU packages:
http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
e.g. it uses 'datarootdir' ($prefix/share), 'sysconfdir' (/etc or
$prefix/etc - I don't know exactly), and 'bindir' ($prefix/bin).
The default prefix is apparently '/usr/local' and package managers will
of course override this with e.g. '/usr'. So that explains why your
manually build packages end up at a different place than those packaged
by your distribution. That's probably the entire purpose of having a
/usr/local: that way your manually compiled packages do not mess up with
those managed by the package manager.
Note that the spatch(.opt) executable is installed in
$prefix/share/coccinelle together with the coccilib python libraries.
There are scripts in $prefix/bin that call spatch(.opt) with the proper
environment variables set. These also take the right prefix into
account, so that should 'just' work.
So that explains why '/usr/bin/spatch' is not the one that you compiled
yourself. It also prioritizes the /usr/local version over the /usr/bin
version so that's perfect.
Now, what I don't understand is why there are old versions lurking
around in your /usr/local/{bin,share/coccinelle} directories. It's
probably better to get rid of the old files first before installing any
new files, but still that should just work.
Except... perhaps I do have an explanation. Note that by default 'make'
only builds the unoptimized bytecode version of spatch. So, if an old
but optimized version already exists in /usr/local/share/coccinelle,
then you end up with the situation that you have a new
/usr/local/share/coccinelle/spatch but an old
/usr/local/share/coccinelle/spatch.opt. The script
'/usr/local/bin/spatch' calls the optimized spatch if it's available (=
usually the best), but in this case it would call the old spatch.opt
because it doesn't know about version numbers.
(in contrast, the scripts /usr/local/bin/spatch.{byte,opt} don't do this
auto-selection)
That's easy to test: remove /usr/local/share/coccinelle/spatch.opt and
check /usr/local/bin/spatch -version. Anyway, you probably want the
optimized versino of spatch anyway, so for that run configure with the
'--enable-release' flag so that 'make' builds the optimized version.
Alternative, or run 'make opt-only' and then 'make install'.
Perhaps that our installation procedure should remove possibly
conflicting files from the coccinelle's share directory during
installation...
Finally, about the regexp support. Apparently, libpcre was not detected
by configure otherwise it would have been enabled (check perhaps
config.log). Does 'pkg-config --list-all' show 'pcre' somewhere? Or, in
case that you don't have pkg-config, does '/usr/include/pcre.h' exist?
Either the detection for the package needs to be improved, or perhaps
you don't have the 'libpcre-dev' package installed (or whatever it may
be called). The 'dev' version contains additional files that allows a
program to be compiled against it, whereas the 'runtime' version
contains only what is needed to run a program that was compiled already.
Arie
_______________________________________________
Cocci mailing list
[email protected]
http://lists.diku.dk/mailman/listinfo/cocci
(Web access from inside DIKUs LAN only)
