VMD-L Mailing List

From: Benjamin Kaduk (kaduk_at_mit.edu)
Date: Thu Sep 12 2013 - 18:19:33 CDT

Hi Johannes,

On Thu, 12 Sep 2013, Johannes Schauer wrote:

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

I remember having to patch that for FreeBSD, too. I don't remember
whether I remembered to send it back to this list for inclusion, though.
:-/

> 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

I agree that that is poor, but don't have visibility into the history of
the code and can't say whether there was a reason for doing it this way.

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

Not all OSes aim for FHS compliance; some (e.g., FreeBSD) have their own
hierarchy standards which are somewhat different. Likewise, the canonical
path for perl on a FreeBSD system is in fact in /usr/local/bin/ (though
the packaging does provide an option to provide compatibility symlinks in
/usr/bin/ , as a version of perl was once provided by the base system). I
think for these sorts of things, we as packagers should probably not push
too hard for upstream to adopt our particular directory layout, and expect
that there will always be some things which we will need to patch. (That
said, I do think there's a better place than /usr/lib for image files.)

-Ben Kaduk