VMD-L Mailing List

From: Giacomo Fiorin (giacomo.fiorin_at_gmail.com)
Date: Sat Mar 28 2020 - 15:53:53 CDT

Hi FX, most modern OS versions of course should (and do) support C++11.
But ancient distributions are still around, especially when they are used
to run on specialized hardware (clusters or workstations). RedHat 6 (i.e.
GCC 4.4) is still supported until November of this year, and there is
optional extended support (paid, of course) well beyond the end of life as
well:
https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates

Together with others, I faced the same problem when contributing code to
VMD, whose build recipes and precompiled builds do not assume C++11
syntax. We agreed to compile the new code conditionally, using #if
(__cplusplus >= 201103L) and document this best we could.
https://github.com/Colvars/colvars/pull/249
https://colvars.github.io/README-c++11.html

When building VMD to test these features, or using them in production, one
may need to change the compiler flags (unless using a recent compiler) to
get a fully-featured version. One of the possible ways to handle this (not
the only way, of course) is here:
https://github.com/giacomofiorin/vmd-patches/blob/master/c%2B%2B11/c%2B%2B11.diff

In your case, you're designing a plugin, which is built independently from
VMD itself, so you should be able to set the compiler flags that you need,
including setting the C++11 standard in a way that's as much portable as
possible.

Given that the platform (most likely RedHat 6) where John will build the
new version of VMD won't support C++11, you could make your plugin optional
(e.g. like the AMBER netcdf plugin, which depends on the availability of
the needed libraries). So the plugin wouldn't be included by default in
most of the VMD official builds, but it definitely would be in other VMD
builds made on more recent Linux systems, or future VMD versions. See e.g.
https://vmd.robinbetz.com/ for an example of how VMD can be built with a
current Python version, for example.

In summary, it's a good idea to work with John on getting the plugin to be
a part of VMD. But in my opinion you shouldn't feel obliged to rewrite a
big chunk of code just to work around the lack of a now established
standard.

Giacomo

On Sat, Mar 28, 2020 at 3:07 PM FX <fxcoudert_at_gmail.com> wrote:

> Dear John,
>
> > It would be great to have a full CIF plugin available in VMD,
> > whether using Gemmi, or by other means.
>
> I’m happy to use another C/C++ library for CIF, but I haven’t found one
> that would fit the bill: most libraries only read a subset (mmCIF for
> example). Gemmi seems like the best option, and the fact that it’s
> header-only makes it a simple dependency. The licence is permissive, which
> is a good thing as well.
>
>
> > One complication is that it's described as being based C++11.
> > If accurate, this creates a compiler dependency that is incompatible
> > with a large number of existing production systems in the field, so
> > we can't expect to provide a pre-compiled binary that would work
> > on any but the latest Linux distros, for example.
>
> I must say I’m a bit surprised, I thought C++11 support was now a standard
> compiler feature. For GCC, I find that GCC 4.8.1 was the first
> feature-complete implementation of the 2011 C++ standard. It was released
> in May 2013, and all distributions seem to ship that or something more
> recent. Even Debian oldoldstable (jessie) ships GCC 4.9.2.
>
>
> > There are a number of ways of doing this.
> > And you can always force a file to be loaded with a specific plugin
> > using the graphical interface in VMD. (choose the plugin to use manually
> > rather than automatically)
>
> That’s a big drawback.
>
> > Something that would make this easier would be to add some new code and
> > scripting APIs (maybe a GUI also) to allow a user preference
> > for a specific plugin to be associated with a file extension rather than
> > the default sorting by plugin major/minor version numbers.
>
> Is it possible to combine two plugins into one? For example, when two
> plugins are registered for a given file extension, let them (in any order
> suitable) try to load the file, and if they fail to open it, given the
> other plugins registered with this extension a chance?
>
> Or simply, should I implement the Gemmi-based reading code as part of the
> existing plugin registered with CIF files?
>
> Cheers,
> FX
>
> 

-- 
Giacomo Fiorin
Associate Professor of Research, Temple University, Philadelphia, PA
Research collaborator, National Institutes of Health, Bethesda, MD
http://goo.gl/Q3TBQU
https://github.com/giacomofiorin