Hi Werner and Andrew:
Debian testing (my new platform) supports D version 1 only up to gcc
version 4.4, but if you use any more modern tool chain such as
gcc-4.5 or 4.6 all support for version 1 stopped, and they moved
to version 2 of D. From the Wikipedia article on the D
programming language, version 1 has been in maintenance mode
since 2007 while version 2 stabilized in 2010.
My take from these facts is it is probably long past time that we moved
to D version 2.
If you agree, here is what you need to do on Linux to get started
with this:
Index: cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake
===================================================================
--- cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake
(revision 12213)
+++ cmake/modules/language_support/cmake/CMakeTestDCompiler.cmake
(working copy)
@@ -88,8 +88,8 @@
OUTPUT_VARIABLE OUTPUT)
ELSE(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
TRY_COMPILE(CMAKE_D_PHOBOS_WORKS ${CMAKE_BINARY_DIR}
${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/testDCompiler.d
- CMAKE_FLAGS "-DLINK_LIBRARIES=gphobos"
- OUTPUT_VARIABLE OUTPUT)
+ CMAKE_FLAGS "-DLINK_LIBRARIES=gphobos2"
+ OUTPUT_VARIABLE OUTPUT)
ENDIF(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
ELSE(CMAKE_COMPILER_IS_GDC)
IF(${CMAKE_SYSTEM_NAME} STREQUAL "Windows")
Index: cmake/modules/language_support/cmake/Platform/Linux-gdc.cmake
===================================================================
--- cmake/modules/language_support/cmake/Platform/Linux-gdc.cmake
(revision 12213)
+++ cmake/modules/language_support/cmake/Platform/Linux-gdc.cmake
(working copy)
@@ -25,7 +25,7 @@
ENDFOREACH(item)
ENDIF(CMAKE_D_BUILD_DOCS)
-SET (CMAKE_D_FLAGS_INIT "-fversion=Posix ${DSTDLIB_FLAGS}")
+SET (CMAKE_D_FLAGS_INIT "-fversion=Unix ${DSTDLIB_FLAGS}")
SET (CMAKE_D_FLAGS_DEBUG_INIT "-g ${DDOC_FLAGS}")
SET (CMAKE_D_FLAGS_MINSIZEREL_INIT "-Os ${DDOC_FLAGS}")
SET (CMAKE_D_FLAGS_RELEASE_INIT "-O3 -fomit-frame-pointer -fweb -frelease
-finline-functions ${DDOC_FLAGS}")
Index: cmake/modules/language_support/cmake/CMakeDInformation.cmake
===================================================================
--- cmake/modules/language_support/cmake/CMakeDInformation.cmake
(revision 12213)
+++ cmake/modules/language_support/cmake/CMakeDInformation.cmake
(working copy)
@@ -215,7 +215,7 @@
IF(CMAKE_D_USE_PHOBOS)
IF(CMAKE_COMPILER_IS_GDC)
SET(DSTDLIB_TYPE "-fversion=Phobos")
- SET(DSTDLIB_FLAGS "-lgphobos")
+ SET(DSTDLIB_FLAGS "-lgphobos2")
ELSE(CMAKE_COMPILER_IS_GDC)
SET(DSTDLIB_TYPE "-version=Phobos")
SET(DSTDLIB_FLAGS "-L${D_PATH}/lib -lphobos")
This patch is sufficient that the small test programme that is run
automatically when we enable the D language actually works
without issues. However, I have not yet applied this patch
because I am waiting for further input from you two about some
version 1 issues that appear in our bindings code
The start of those error messages is
/home/software/plplot_svn/HEAD/plplot_cmake_qt/bindings/d/plplot.d:57: Error:
cannot implicitly convert expression (c_args.length) of type ulong to int
/home/software/plplot_svn/HEAD/plplot_cmake_qt/bindings/d/plplot.d:64: Error:
cannot implicitly convert expression (u.length) of type ulong to int
/home/software/plplot_svn/HEAD/plplot_cmake_qt/bindings/d/plplot.d:65: Error:
cannot implicitly convert expression (u[0LU].length) of type ulong to int
I got rid of the first error message (and many more concerning
toStringz) by replacing it everywhere by cast(char *)toStringz. (I
have not committed this change.) And I think I could get rid of most
of the rest of the messages concerning "implicitly convert" by doing
similar explicit casting. But if I use grep to artificially remove
all error messages from the output that have the "implicitly convert"
string in the error message that leaves 23 error messages starting with
/home/software/plplot_svn/HEAD/plplot_cmake_qt/bindings/d/plplot.d:165: Error:
function plplot.c_plcont (double** f, int nx, int ny, int kx, int lx, int ky,
int ly, double* clevel, int nlevel, void C function(double, double, double*,
double*, void*) pltr, void* pltr_data) is not callable using argument types
(double**,int,int,int,int,int,int,double*,ulong,void C function(double, double,
double*, double*, void*),void*)
/home/software/plplot_svn/HEAD/plplot_cmake_qt/bindings/d/plplot.d:183: Error:
function plplot.c_plcont (double** f, int nx, int ny, int kx, int lx, int ky,
int ly, double* clevel, int nlevel, void C function(double, double, double*,
double*, void*) pltr, void* pltr_data) is not callable using argument types
(double**,int,int,int,int,int,int,double*,ulong,void C function(double, double,
double*, double*, void*),_N7*)
/home/software/plplot_svn/HEAD/plplot_cmake_qt/bindings/d/plplot.d:210: Error:
function plplot.c_plcont (double** f, int nx, int ny, int kx, int lx, int ky,
int ly, double* clevel, int nlevel, void C function(double, double, double*,
double*, void*) pltr, void* pltr_data) is not callable using argument types
(double**,int,int,int,int,int,int,double*,ulong,void C function(double, double,
double*, double*, void*),_N8*)
which I don't know how to deal with. And once the version 2 errors in
the bindings are dealt with, I assume there will be some version
2 issues to deal with in the D examples as well.
I would be willing to help with some of the scut work required for
this proposed conversion to version 2 of D such as the above change in
CMake language support for D and the above cast() changes, but I would
need you guys to do the heavy lifting (such as dealing with the above
second set of errors not involving simple implicit casting issues).
Do you agree we should move to version 2 of D, and if so how
do you want to organize the work between the three of us?
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
__________________________
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
