From: Jim D. <ji...@di...> - 2008-05-21 07:57:24
|
After a long absence on Plplot development, I decided to cleanup my patches and get them worked back into the main trunk. Some of these patches were submitted previously, however, they didn't seem to make it into the trunk. First, the fortran 95 bindings are still a bit goofed up when using Intel Fortran (at least they were for me when I built both the 5.8.0 and the trunk using CMake 2.6.0). The problem is that plstubs.h is not generating the correct symbols. I have a patch--who wants to review and commit it? Second, I have a better way of generating the plflt.inc file that avoids building an executable and uses the C preprocessor instead. My CMake edit is a crude and could be refined. Anyone care to help out? Third, CMake does not provide an option for omitting the default library information when building with MSVC. This is an issue if you want to build a runtime independent library. A runtime independent library is handy because you do not have to build a debug version, a non-debug version, a static version, a multithreaded version, etc. The other option is to have the person using Plplot specify /nodefaultlib:<library> as a linker option. I find that option less desireable than building a runtime independent version of Plplot. I have a fix, but it involves making a minor edit to several CMakeLists.txt files. I could not find a cleaner method for implementing the capability. Someone who is more adept at CMake may have a better way. Incidentally, I'm still working on an improved win32 viewer--the task moved to the backburner when I lost my hard drive last year (or so). |
From: Arjen M. <arj...@wl...> - 2008-05-21 09:26:51
|
Jim Dishaw wrote: >After a long absence on Plplot development, I decided to cleanup my >patches and get them worked back into the main trunk. Some of these >patches were submitted previously, however, they didn't seem to make it >into the trunk. > >First, the fortran 95 bindings are still a bit goofed up when using >Intel Fortran (at least they were for me when I built both the 5.8.0 and >the trunk using CMake 2.6.0). The problem is that plstubs.h is not >generating the correct symbols. I have a patch--who wants to review and >commit it? > > I would like to take on that task, as I have been responsible for the original ones. Intel Fortran uses a different set of conventions than Compaq Visual Fortran that affect the interfacing to C. I am not quite sure how we cover that, but apparently you have found problems with the current code. >Second, I have a better way of generating the plflt.inc file that avoids >building an executable and uses the C preprocessor instead. My CMake >edit is a crude and could be refined. Anyone care to help out? > > Certainly, let me see it :). >Third, CMake does not provide an option for omitting the default >library information when building with MSVC. This is an issue if you >want to build a runtime independent library. A runtime independent >library is handy because you do not have to build a debug version, a >non-debug version, a static version, a multithreaded version, etc. The >other option is to have the person using Plplot specify >/nodefaultlib:<library> as a linker option. I find that option less >desireable than building a runtime independent version of Plplot. > >I have a fix, but it involves making a minor edit to several >CMakeLists.txt files. I could not find a cleaner method for >implementing the capability. Someone who is more adept at CMake may >have a better way. > > Hm, that does sound interesting. Is this a problem with MSVC only? How does this change with the later versions of MSVC (7, 8, ...)? (I usually try to avoid getting involved in these issues, but I do not always succeed.) Regards, Arjen |
From: Jim D. <ji...@di...> - 2008-05-21 13:09:21
|
Arjen Markus writes: > Jim Dishaw wrote: > >>Third, CMake does not provide an option for omitting the default >>library information when building with MSVC. This is an issue if you >>want to build a runtime independent library. A runtime independent >>library is handy because you do not have to build a debug version, a >>non-debug version, a static version, a multithreaded version, etc. The >>other option is to have the person using Plplot specify >>/nodefaultlib:<library> as a linker option. I find that option less >>desireable than building a runtime independent version of Plplot. >> > Hm, that does sound interesting. Is this a problem with MSVC only? How > does this change with the later versions of MSVC (7, 8, ...)? (I > usually try to avoid getting involved in these issues, but I do not > always succeed.) > >From what I can tell, almost all versions of MSVC put default library information into the .obj file. The only exceptions maybe some of the really old ones. The available default libraries are: libcmt Multithreaded, static link msvcrt Multithreaded, dynamic link (e.g. MSVCR80.DLL) libcmtd Multithreaded, static link, debug msvcrtd Multithreaded, dynamic link, debug msvcmrt C Runtime import library for CLR msvcurt C Runtime import library for pure MSIL code Older version of MSVC had libc Singlethreaded, static link libcd Singlethreaded, static link, debug The changes that I have so far (they may not be pretty because my grasp of CMake is weak): In UserOverride.cmake message(STATUS "NOTICE: Checking for MSVC on WIN32") if(WIN32) if(MSVC) message(STATUS "NOTICE: MSVC, setting /Zl for library builds") # Copied from the CMake defaults as of 2.6.0 # W3 = Warning Level 3 # Zm1000 = Max Memory Allocation (% of default) # Zl = Omit default library information SET (LIB_C_FLAGS "/DWIN32 /D_WINDOWS /W3 /Zm1000 /Zl") if(CMAKE_BUILD_TYPE MATCHES "Debug") # Zi = Enable debugging information # Ob0 = Disable inline expansion # Od = Disable optimization # RTC1 = Enable fast checks SET (LIB_C_FLAGS_DEBUG "/D_DEBUG /Zi /Ob0 /Od /RTC1") endif(CMAKE_BUILD_TYPE MATCHES "Debug") endif(MSVC) if(TARGET_FORTRAN MATCHES "IVF") SET(TARGET_LIB_FC_FLAGS "${CMAKE_FC_FLAGS} /libdir:none") endif(TARGET_FORTRAN MATCHES "IVF") endif(WIN32) Next, in the CMakeLists.txt files that are in src, bindings, drivers, and lib need to have the following added if(WIN32 AND MSVC) SET(CMAKE_C_FLAGS "${LIB_C_FLAGS}") SET(CMAKE_C_FLAGS_DEBUG "${LIB_C_FLAGS_DEBUG}") endif(WIN32 AND MSVC) These changes basically create a different set of C flags (I left C++ alone because I was not sure if this is the best way to implement this, however it could be added with CXX_FLAGS) for files that are destined to go into the library. Additional work is needed to get this working for DLL builds--I did not put the effort in because there may be a better way. Cheers, -jd |
From: Jim D. <ji...@di...> - 2008-05-21 13:22:30
Attachments:
plplot-plflt.patch
plflt.txt
|
Arjen Markus <arj...@wl...> writes: > Jim Dishaw wrote: > >>Second, I have a better way of generating the plflt.inc file that avoids >>building an executable and uses the C preprocessor instead. My CMake >>edit is a crude and could be refined. Anyone care to help out? >> >> > Certainly, let me see it :). > I added a new file in bindings/f95 called plflt.txt (I picked .txt to make sure it would not conflict with a traditional source file, however, a better name might be better). Then I applied the attached patch to bindings/f95/CMakeLists.txt. I was conservative and restricted it to WIN32, however, there is no reason it should not apply to all platforms. There probably is a better way to get it to work, so applying this patch might not be the best way forward. |
From: Arjen M. <arj...@wl...> - 2008-05-27 11:22:49
|
Jim Dishaw wrote: >Arjen Markus writes: > > > >>Jim Dishaw wrote: >> >> >> >>>Third, CMake does not provide an option for omitting the default >>>library information when building with MSVC. This is an issue if you >>>want to build a runtime independent library. A runtime independent >>>library is handy because you do not have to build a debug version, a >>>non-debug version, a static version, a multithreaded version, etc. The >>>other option is to have the person using Plplot specify >>>/nodefaultlib:<library> as a linker option. I find that option less >>>desireable than building a runtime independent version of Plplot. >>> >>> >>> >>Hm, that does sound interesting. Is this a problem with MSVC only? How >>does this change with the later versions of MSVC (7, 8, ...)? (I >>usually try to avoid getting involved in these issues, but I do not >>always succeed.) >> >> >> > >>From what I can tell, almost all versions of MSVC put default library >information into the .obj file. The only exceptions maybe some of the >really old ones. The available default libraries are: > >libcmt Multithreaded, static link >msvcrt Multithreaded, dynamic link (e.g. MSVCR80.DLL) >libcmtd Multithreaded, static link, debug >msvcrtd Multithreaded, dynamic link, debug >msvcmrt C Runtime import library for CLR >msvcurt C Runtime import library for pure MSIL code > >Older version of MSVC had > >libc Singlethreaded, static link >libcd Singlethreaded, static link, debug > >The changes that I have so far (they may not be pretty because my grasp >of CMake is weak): > >In UserOverride.cmake > >message(STATUS "NOTICE: Checking for MSVC on WIN32") >if(WIN32) > if(MSVC) > message(STATUS "NOTICE: MSVC, setting /Zl for library builds") > # Copied from the CMake defaults as of 2.6.0 > # W3 = Warning Level 3 > # Zm1000 = Max Memory Allocation (% of default) > # Zl = Omit default library information > SET (LIB_C_FLAGS "/DWIN32 /D_WINDOWS /W3 /Zm1000 /Zl") > if(CMAKE_BUILD_TYPE MATCHES "Debug") > # Zi = Enable debugging information > # Ob0 = Disable inline expansion > # Od = Disable optimization > # RTC1 = Enable fast checks > SET (LIB_C_FLAGS_DEBUG "/D_DEBUG /Zi /Ob0 /Od /RTC1") > endif(CMAKE_BUILD_TYPE MATCHES "Debug") > endif(MSVC) > > if(TARGET_FORTRAN MATCHES "IVF") > SET(TARGET_LIB_FC_FLAGS "${CMAKE_FC_FLAGS} /libdir:none") > endif(TARGET_FORTRAN MATCHES "IVF") >endif(WIN32) > >Next, in the CMakeLists.txt files that are in src, bindings, drivers, >and lib need to have the following added > >if(WIN32 AND MSVC) > SET(CMAKE_C_FLAGS "${LIB_C_FLAGS}") > SET(CMAKE_C_FLAGS_DEBUG "${LIB_C_FLAGS_DEBUG}") >endif(WIN32 AND MSVC) > >These changes basically create a different set of C flags (I left C++ >alone because I was not sure if this is the best way to implement this, >however it could be added with CXX_FLAGS) for files that are destined to >go into the library. > >Additional work is needed to get this working for DLL builds--I did not >put the effort in because there may be a better way. > > This looks okay to me, but perhaps we should try and append, rather than replace, the flags that suppress the default libraries. That way we can retain all other flags. I am not sure about DLLs, but we will certainly have to look into that aspect. Regards, Arjen |
From: Jim D. <ji...@di...> - 2008-05-27 12:29:57
|
Arjen Markus <arj...@wl...> writes: > This looks okay to me, but perhaps we should try and append, rather > than replace, the flags that suppress the default libraries. That way > we can retain all other flags. > > I am not sure about DLLs, but we will certainly have to look into that > aspect. > I only did the replace because I do not how to remove one option that was in the middle of the string. The CMake C module has a /MDd in the middle of CMAKE_C_FLAGS_DEBUG_INIT and CMAKE_CXX_FLAGS_DEBUG_INIT. If we remove the /MDd when building a library, then we should be good. -jd |
From: Arjen M. <arj...@wl...> - 2008-05-27 11:26:54
|
Jim Dishaw wrote: >Arjen Markus <arj...@wl...> writes: > > > >>Jim Dishaw wrote: >> >> >> >>>Second, I have a better way of generating the plflt.inc file that avoids >>>building an executable and uses the C preprocessor instead. My CMake >>>edit is a crude and could be refined. Anyone care to help out? >>> >>> >>> >>> >>Certainly, let me see it :). >> >> >> > >I added a new file in bindings/f95 called plflt.txt (I picked .txt to >make sure it would not conflict with a traditional source file, however, >a better name might be better). Then I applied the attached patch to >bindings/f95/CMakeLists.txt. I was conservative and restricted it to >WIN32, however, there is no reason it should not apply to all >platforms. There probably is a better way to get it to work, so >applying this patch might not be the best way forward. > > > >------------------------------------------------------------------------ > >Index: CMakeLists.txt >=================================================================== >--- CMakeLists.txt (revision 8414) >+++ CMakeLists.txt (working copy) >@@ -29,6 +29,16 @@ > ${CMAKE_CURRENT_BINARY_DIR} > ) > >+if(WIN32) >+# Call the C preprocessor to generate the .inc file. There probably >+# is a better way to do this, but this works >+FILE(TO_NATIVE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/plflt.txt" SRC_FILE) >+FILE(TO_NATIVE_PATH "${CMAKE_CURRENT_BINARY_DIR}/plflt.inc" INC_FILE) >+FILE(TO_NATIVE_PATH "${CMAKE_BINARY_DIR}/include" INC_PATH) >+add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/plflt.inc >+ COMMAND ${CMAKE_C_COMPILER} /I${INC_PATH} /EP ${SRC_FILE} > ${INC_FILE} >+) >+else(WIN32) > # Build plflt to determine KIND for PLFLT > set(plflt_SRC > plflt.c >@@ -46,6 +56,7 @@ > COMMAND ${CMAKE_CURRENT_BINARY_DIR}/plflt > DEPENDS ${plflt_LOCATION} > ) >+endif(WIN32) > > set_source_files_properties(plflt.inc PROPERTIES GENERATED ON) > > > >------------------------------------------------------------------------ > >#include "plConfig.h" > >!Dummy file used to generate the plflt.inc include file >! >! Type of floating-point numbers in PLplot >! >#ifdef PL_DOUBLE >integer, parameter :: plf = kind(1.0d0) >#else >integer, parameter :: plf = kind(1.0) >#endif >integer, parameter :: plflt = plf > > This patch would only work with MSVC - I mean: the avoidance of creating an executable that then creates the include file. Perhaps we can do this even simpler: Use CMake itself to write this file. Whether we use single or double precision is controlled via a CMake variable/option, PL_DOUBLE. So we can use this to write the one or two lines we need to write. Regards, Arjen |
From: Jim D. <ji...@di...> - 2008-05-27 12:34:06
|
Arjen Markus <arj...@wl...> writes: > Perhaps we can do this even simpler: > Use CMake itself to write this file. Whether we use single or double > precision is controlled via a CMake variable/option, PL_DOUBLE. > So we can use this to write the one or two lines we need to write. > > Regards, > > Arjen Your solution is better. My CMake knowledge is quite limited. -jd |
From: Jim D. <ji...@di...> - 2008-06-03 04:36:17
Attachments:
plplot-f95.patch
|
Arjen Markus <arj...@wl...> writes: > Perhaps we can do this even simpler: > Use CMake itself to write this file. Whether we use single or double > precision is controlled via a CMake variable/option, PL_DOUBLE. > So we can use this to write the one or two lines we need to write. > I have attached a patch that implements your suggestion. The patch also include my other Fortran changes that have not been applied yet. |
From: Arjen M. <arj...@wl...> - 2008-06-03 13:20:17
|
> Arjen Markus <arj...@wl...> writes: > >> Perhaps we can do this even simpler: >> Use CMake itself to write this file. Whether we use single or double >> precision is controlled via a CMake variable/option, PL_DOUBLE. >> So we can use this to write the one or two lines we need to write. >> > > I have attached a patch that implements your suggestion. The patch also > include my other Fortran changes that have not been applied yet. > > I have applied this patch to my working copy and it works fine - except for the flag CVF as that causes a conflicting calling convention (it should be __stdcall when compiling with default flags for Compaq Visual Fortran). In the process of testing this I ran into a few other issues. I will separately report them. There is at least one CMake issue involved. Regards, Arjen |
From: Jim D. <ji...@di...> - 2008-06-04 09:25:34
|
"Arjen Markus" <arj...@wl...> writes: >> Arjen Markus <arj...@wl...> writes: >> >>> Perhaps we can do this even simpler: >>> Use CMake itself to write this file. Whether we use single or double >>> precision is controlled via a CMake variable/option, PL_DOUBLE. >>> So we can use this to write the one or two lines we need to write. >>> >> >> I have attached a patch that implements your suggestion. The patch also >> include my other Fortran changes that have not been applied yet. >> >> > > I have applied this patch to my working copy and it works fine > - except for the flag CVF as that causes a conflicting calling > convention (it should be __stdcall when compiling with default > flags for Compaq Visual Fortran). > > In the process of testing this I ran into a few other issues. > I will separately report them. There is at least one CMake > issue involved. > I don't have CVF installed on my machine right now, so I was not able to test it. I guess you got it working with the default, in which case we might be able to do away with the CVF define. -jd |
From: Arjen M. <arj...@wl...> - 2008-06-04 09:50:33
|
> I don't have CVF installed on my machine right now, so I was not able to > test it. I guess you got it working with the default, in which case we > might be able to do away with the CVF define. > Okay, that sounds reasonable :). ISTR CVF has an option to change that behaviour but we will rely on the defaults as provided by CMake. Regards, Arjen |