[Plplot-devel] D language support topic

[Alan W. I. <Ala...@gm...>]

Some essential background information for this post is "D" is an
interesting and distinct computer language that is a re-engineered
version of C++.  Presumably because of all the programmer interest in
"D", there are three well-known D compilers with free software
licenses.  They are

1. dmd (the fundamental D compiler from "Digital Mars" which
effectively sets the D syntax standards);

2. ldc (a D compiler with dmd front-end [the part of the compiler that
transforms D syntax to a language-independent intermediate
representation] and LLVM back-end); and

3. gdc (the GNU-implemented D compiler which has its own unique
    front-end and gcc backend).

My own Debian Buster platform gives me access to official ldc and gdc
packages, and I have built a working dmd on that platform from the
Digital Mars source code for that compiler.  So I think with some work
all developers here with access to Unix platforms and an interest in
"D" should be able to gain access to all three compilers.

The D compiler choice is more limited on Windows.  For example, there
are no official packages for ldc and gdc on Cygwin or MSYS2 so I
suspect both compilers would need a lot of work before they worked on
Windows.  However, dmd is apparently available for all Windows
platforms as a free download from Digital Mars so developers here who
are limited to just Windows platforms can still try out our D binding
and examples once I make dmd one of the compilers that are correctly
supported for the PLplot needs by our CMake D language support logic.

I started this development topic a few days ago in response to
<https://sourceforge.net/p/plplot/patches/35/> where the poster's
commentary indicated the installed D examples would not traditionally
compile with dmd, and his substantial patch to the source code for the
D examples fixed all such issues except for x16d (where his issue for
that example may have been due to the differences between the
gdc-built plplotdmd library that was presumably installed and the
dmd-built examples).  I have since been able to update our D examples
(on a private topic branch which I plan to push in due course) with
that patch and show that gdc D compiler was able to compile and run
those updated examples without run-time or diff-report issues in our
build tree.

So that (examples that now work locally for me with gdc and externally
for someone else with dmd) is a promising start to this topic, but to
finish it I want to generalize our CMake D language support logic and
overall logic so that the ldc and dmd D compilers work as well for me
as the gdc compiler currently does for our 3 different D builds (the
CMake-based build of our D binding and examples, the CMake-based build
of our installed D examples that are linked to our installed D
binding, and the traditional (Makefile + pkg-config) build of our
installed D examples that are linked to our installed D binding).

Our current CMake D language support (located in
cmake/modules/language_support/cmake) was forked by Werner Smekal from
the (now defunct) CMakeD project in 2009.  My comprehensive tests show
our fork does support gdc well on Linux (except for some known
limitations such as being forced to use a static version of the
plplotdmd library).  Our fork does have dmd support which might have
been tested by Werner in 2009, but I don't think anyone has tested it
since with dmd.  Our fork has no support for ldc.

Our changes to the 2009 version of CMakeD have been fairly small but
significant, but since then there have been other more substantial
changes and forks of that project culminating with the cmake-d project
at <https://github.com/dcarp/cmake-d> which continues to be actively
developed.  Note that project advertises that it supports all three of
dmd, ldc, and gdc.  That ldc support is just not available with our
fork of CMakeD, and I think it is quite likely (modulo a few modest
changes like the rpath one below) that cmake-d has better support for
dmd than our fork.

So I tried gdc with cmake-d language support (accessed externally),
and I ran into an rpath issue which should easily be fixed (since our
fork of CMakeD does handle rpath well) but which I temporarily worked
around with LD_LIBRARY_PATH.  They results of that experiment were
perfect (no run-time or diff report issues with the updated D
examples).

So replacing our ancient fork of CMakeD with a modern fork of cmake-d
currently looks like the proper way forward.  However, before implementing
that I need to do more comparisons between the two CMake D language
support projects for dmd, and assuming I can get dmd to work correctly
for our needs for cmake-d using modest changes to cmake-d, I also need
to try out lcd (not available for our ancient fork of CMakeD) using
cmake-d.

More later.

Alan
__________________________
Alan W. Irwin

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.org); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________