On 2014-04-08 10:45+0200 Thorsten Behrens wrote:
> Hi Alan!
> [Alan said:]
>> Thorsten (or anybody else here) if you do have access to a D compiler
>> on Windows and want to look further into D language support on that
>> platform, I would encourage you to experiment with Windows-only
>> changes to our D language support files (using -DENABLE_d=ON), but
>> otherwise I don't think it is possible to figure out what changes are
>> needed in those files for the Windows case.
>
> I will give this a try today. According to the CMakeDInformation two
> compilers seem of interest, DMD and GDC. Because the erroneous linker flag
> is in the non-GDC branch, I will do my tests using DMD.
That would be great.
By the way, I agree with you the present logic for setting general
non-D variables (that affect all compilers) such as
CMAKE_LIBRARY_PATH_FLAG, CMAKE_LIBRARY_PATH_FLAG, and
CMAKE_LIBRARY_PATH_TERMINATOR cannot be correct. The present overall
logic for doing that is
IF(CMAKE_COMPILER_IS_GDC
# Set D-related variables
[...]
# Set general variables
[...]
ELSE(CMAKE_COMPILER_IS_GDC)
IF(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
# Set D-related variables
[...]
# Set general variables
[...]
ELSE(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
# Set D-related variables
[...]
# Set general variables
[...]
ENDIF(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
ENDIF(CMAKE_COMPILER_IS_GDC)
One of the problem (as I see it) is that
ELSE(CMAKE_COMPILER_IS_GDC)
clause which means every compiler is affected (as you found out) by whatever is
set
for the general variables for the non-GDC case. I would suggest replacing that
clause by
ELSEIF(CMAKE_COMPILER_IS_DMD)
as an experiment to see whether that stops the cross-talk with the
other compilers. Of course, that change has nothing to do with the
variables that need to be set to get DMD to work in the Windows case
so additional experiments will likely be required to get that working.
By the way, I don't think the DMD compiler support has been tested on
any platform yet. According to
http://en.wikipedia.org/wiki/D_(programming_language), DMD is not
completely open source software. Thus, Debian (and presumably most
other Linux distributions) aren't allowed to distribute it. So all
our testing so far of the D binding for PLplot has been done with GDC.
Also, I don't think GDC has been tested on the Windows platform so if
you get a chance to do such testing as well as the DMD testing you
have planned, that would be great.
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
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.sf.net); 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
__________________________
------------------------------------------------------------------------------
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
