VMD-L Mailing List

From: Johannes Schauer (j.schauer_at_email.de)
Date: Thu Sep 12 2013 - 07:18:32 CDT

Dear vmd community,

we are using vmd at my university and to simplify installation, I improved the
Debian packaging for vmd 1.9.1. Along with it, I have a few patches, comments
and other suggestions for improvements.

First of all, I want to thank you for creating this piece of software. While I
am happy that its license allows me to modify vmd for my needs, it does not
seem to be possible for me to redistribute vmd to others. Was it ever
considered to lift this restriction? I can see various positive effects if it
was allowed to distribute vmd for example along with Linux distributions like
Debian. What are the reasons which are not outweighed by the potential amount
of new users and developers through simply an easier accessibility of vmd?

Next, I want to present a number of patches which I'm currently applying to
vmd. Maybe they can be considered to be integrated in the next vmd release. The
patches are by me and Michael Banck and others of the debichem team.

-------------------------------------------------------------------------------

adjust_install_path_in_configure.patch: http://mister-muffin.de/p/kmZO.txt

This patch improves configure to create a Makefile which respects the DESTDIR
environment variable. This is needed because during packaging, the software is
installed into a subdirectory given in the DESTDIR environment variable.

-------------------------------------------------------------------------------

plugins_build.patch: http://mister-muffin.de/p/NUtp

This patch enables the commented out default case in build.csh of the plugin
source. If neither of the cases is given, then a sensible default should be
executed. If you dont agree with that idea, then please return a non-zero exit
status if the default case is hit. Otherwise, scripts executing build.csh are
of the impression that it executed successfully.

-------------------------------------------------------------------------------

Furthermore, it would be beneficial if the header/library locations can be user
supplied. For example in Debian we use pkg-config to retrieve the correct path
for headers and libraries.

nvcc_path.patch: http://mister-muffin.de/p/9zbD.txt (for cuda)
python_pkg_config.patch: http://mister-muffin.de/p/_vqW.txt (for python)

-------------------------------------------------------------------------------

Some cuda cu files seem to be missing include directives for libthrust, at
least with recent cuda versions. Here a patch that fixes it:

libthrust_device_ptr.patch: http://mister-muffin.de/p/Xgyu

-------------------------------------------------------------------------------

Distributions like Debian like to pass their default compilation parameters to
software builds. In Debian this is for example used to pass hardening flags to
gcc. Unfortunately, vmd does not respect the environment variables CFLAGS,
CXXFLAGS, CPPFLAGS or LDFLAGS being set. The following patch only adds changes
for the LINUXAMD64 target as I can't test the other targets. The changes should
be analog to the LINUXAMD64 target.

hardening.patch: http://mister-muffin.de/p/pnvg

-------------------------------------------------------------------------------

The hesstrans plugin seems to have an error in its makefile resulting in a
recursive variable definition error. The following patch fixes it:

hesstrans_make_fix.patch: http://mister-muffin.de/p/EYLJ.txt

-------------------------------------------------------------------------------

Using -Wl,-rpath is being frowned upon by Debian and other distributions. The
following patch remedies the situation:

no_rpath.patch: http://mister-muffin.de/p/B1X4.txt

-------------------------------------------------------------------------------

Apart from above patches, I have the following remarks to make:

The distrib target in the molfile_plugin Makefile execute successfully even if
no plugin library was built at all. This is because find is executed in a loop
which also succeeds if no file is found at all. It stands to question why find
is used in the first place as only one single file is to be found which can
equally be achieved through shell globbing. I didnt provide a patch to fix
this, as I might've missed some important reason why it is done like this.

Lots of problems I describe above (environment and flag passing, library paths,
custom cflags) could me remedied by switching to a proper cross platform build
system like cmake or autotools. Since the existing makefiles contain lots of
hackery for strange targets I didnt dare to implement this either. Another
reason to use a proper build system could be an even wider compatibility of vmd
with even more platforms.

Other issues are for the tarball which you distribute. It is not as clean as it
should be and I have to execute the following commands to clean it:

# remove CVS directories from sources
find vmd-1.9.1 -name "CVS" -delete
# remove CVS conflict copy
find vmd-1.9.1 -name ".#*" -delete
# remove prebuilt binaries
find vmd-1.9.1 -name "*.dll" -delete
find vmd-1.9.1 -name "*.o" -delete
rm vmd-1.9.1/plugins_source/intersurf/bin/intersurf_WIN32.dll
rm vmd-1.9.1/plugins_source/intersurf/bin/intersurf_LINUX.so
rm vmd-1.9.1/plugins_source/fmtool/fmtool.gcc
rm vmd-1.9.1/plugins_source/fmtool/fmtool.icc
rm vmd-1.9.1/plugins_source/fmtool/fmtool
rm vmd-1.9.1/lib/points/distribute

Could you do this cleaning from your side before distributing the tarball?

Also, vmd installs image files (gif, xbm) into /usr/lib which, according to the
filesystem hierarchy standard is the wrong place for them. Architecture
independent files should go into /usr/share instead.

Could you also fix the executable bits for all files in the tarball? Sometimes
files have the executable bit set even though they are not to be executed. At
other times, files contain a shebang line but no executable bit. Maybe the
shebang line is wrong as well?

Coming to shebang lines, some of those have to be fixed as well. For example it
should not be /usr/local/bin/perl but /usr/bin/perl. And plugins like
autoionize.tcl should read the vmd location from the configure step instead of
hardcoding it to /usr/local/bin/vmd. This, again, would be solved by a proper
cross-platform build system.

What do you think?

cheers, josch