|
From: Nicholas N. <n.n...@gm...> - 2009-02-06 03:44:50
|
Hi,
I have a proposal for simplifying the build system, particularly
installation of files.
Currently things get installed in two ways:
- "in-place": the .in_place directory is always made with "make", it
contains symlinks back to various files in tool dirs.
- "install": it contains copies of files.
The files that are built in the tree have names like:
memcheck-x86-linux, libcoregrind_x86_darwin.a,
vgpreload_memcheck-x86-darwin.so, libmpiwrap-X86_LINUX.so. But when
installed into either .in_place or the installation directory, they
get renamed to x86-linux/{memcheck,libcoregrind.a,vgpreload_memcheck.so,libmpiwrap.so}.
This requires various pieces of appalling sed hackery at install-time.
But I don't see any good reasons for it. I also don't see any good
reason for the inconsistency in the original names, eg. '-' vs '_',
caps vs. non-caps.
I have a patch which gets rid of the platform-specific directory in
the installation dir, and just keeps the platform-specific suffixes on
the various files. The launcher requires minor changes to find
things, but it's not difficult. It cuts out various horrendous parts
of Makefile.am files, some of which are the worst lines in the entire
build system.
It also avoids a big problem on Darwin, which has to do with my old
friends, the .dSYM directories. I need to generate and install
vgpreload_memcheck-x86-darwin.so.dSYM alongside
vgpreload_memcheck-x86-darwin.so. The problem is that the .dSYM
directory has a file within it,
vgpreload_memcheck-x86-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_memcheck-x86-darwin.so.
(In case you're wondering, the two .so files aren't the same -- the
top-level one lacks debug info, the one with .dSYM has it.) But if
the .dSYM dir gets renamed during installation to match the renamed
.so, the internal .so name no longer matches and Valgrind's dSYM debug
info reader gets confused. My patch above which avoids the renaming
fixes this problem. I'd rather not use sed to rename the internal
.so.
There's a possible problems with these installed files: libvex.a,
libvex_coregrind.a, libmpiwrap.so. I think the first two are there in
case you want to distribute your own tool without also distributing
Valgrind. (But we don't include libreplacemalloc_toolpreload.a, so
it's incomplete; I've added that in the patch.) But it wouldn't be
hard to an external tool to adjust to this change, and AFAIK there
aren't any being distributed. (We should probably also change the
library names from e.g. libvex_x86_linux.a to libvex-x86-linux.a.)
Changing x86-linux/libmpiwrap.so to libmpiwrap-x86-linux.so shouldn't
cause many problems, since it's designed to be manually included in a
program by a user. Some people might have scripts that need trivial
updates.
External Valgrind-invoking programs like Valkyrie shouldn't need to be
changed -- they will be calling $INSTALL/bin/valgrind, which hasn't
moved.
Thoughts?
Nick
|