VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Tue Sep 17 2013 - 11:05:14 CDT

Hi Johannes,
  I don't have time to discuss everything in your email today, but I wanted
to give you a few answers to start with:

On Thu, Sep 12, 2013 at 02:18:32PM +0200, Johannes Schauer wrote:
> 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.

Great!

> 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?

There are several motivations here. One of the major ones is that our
funding agencies require us to report the number of registered VMD users.
You'll note that things are done similarly for other software tools in our
field like Chimera, PMV, AMBER, NAMD, and many others. They too likely have
to report their user numbers to their funding agencies.

Another issue is that VMD users expect help and support with getting VMD
running on their systems, and we find it much easier to deal with supporting
builds of VMD we made ourselves, rather than having to track the behavior of
binaries produced by other people without our knowledge. On the one hand, it
would be nice to have VMD in every Linux distribution, but on the other it
would greatly multiply the number of build scenarios we would have to be
aware of. This comes up with strange bugs like the problems that certain
versions of Tcl/Tk have with SCIM (internationalized input), issues with
certain versions of OpenGL headers, CUDA versions, and other library
dependencies that have nothing to do with the code in VMD itself.

If we allowed redistribution, we could no longer count on people using
the "best" library version (from the point of view of VMD specifically).
They would instead be compiling VMD dynamically against "whatever"
version of these library dependencies the Linux distribution preferred.
And for closed source things like CUDA, OptiX, and/or other libraries,
the users of those Linux distributions would likely be missing those
features of VMD by default, which I think is an undesirable outcome.
I have yet to see a Linux distro that ships pre-compiled binaries that
depend on anything that's closed source. I would hate to see a default
build of VMD that disabled CUDA acceleration for example... I don't know
of any open source OpenCL driver, so that too is the same issue.
I would rather that users get full-featured builds of VMD with all of
these components enabled, even if that means that they have to get them
from us, or worst case, by compiling themselves from source.

> 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.

I appreciate your patches, and I will start looking at them later this
week after I get past some deadlines. Hopefully we can accomodate many
of your suggestions, and in cases where we cannot, maybe we can find a
compromise that simplifies things specifically for the Debian community.

Cheers,
  John Stone
  vmd_at_ks.uiuc.edu

> -------------------------------------------------------------------------------
>
> 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 

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/