From: Alan W. I. <ir...@be...> - 2006-08-10 20:46:21
|
Here is the current status of our CBS. Our CBS is virtually complete. Here are the only exceptions I am aware of. Only the first of them is relevant on Linux. * octave is currently missing from our CBS. That component is similar to Tcl/Tk with lots of straightforward details so I expect it will take a while to implement, but I don't expect any serious show-stoppers. Andrew Ross has kindly volunteered to do the job so he will have the honor of finishing off our CBS on Linux. * The aqt device driver for Mac OS X is a work in progress, but it sounds like Hazen is close. * We need a windows-savvy volunteer to implement the sys/win32/msdev/src/win3.cpp device driver once bare windows works. * if CMake works for the djgpp platform (a big if), then Andrew Roach will undoubtedly want to implement the sys/dos/djgpp/src/gnusvga.c device driver. The various non-Linux platforms are beginning to round into shape thanks to the work of others. * On bare windows (visual c++ 2005), Werner tells me that at least the PLplot core is close to building. The one showstopper was how the math library was treated, but I think I have now fixed that so I hope it will build on the next iteration for him. Once that milestone occurs, there will probably be some considerable extra effort required to expand to other language interfaces (e.g., python and java), get examples working, etc., but the bare windows platform is looking quite promising. * PLplot has built on Cygwin and MinGW in the past for Werner, but I have forgotten the completeness of the PLplot language interfaces he was testing, and how far he tested the examples. * As we learned recently from Hazen, PLplot builds okay on Mac except for python. The examples in the build tree work for C and C++, but there are some problems with the fortran examples in the build tree and no examples work yet in the install tree. I expect all these problems are due to minor Mac OS X linking issues for shared libraries that still have to be worked out. Or there may be some "obvious" CMake switch that needs to be turned on for the Mac OS X case. Finally, thanks to the efforts of Andrew Ross and yours truly, our CBS is working reliably on Linux with dynamic device drivers, shared libraries, and separate build tree. Other variations on that platform need testing (e.g., static devices, static libraries, source-tree build, separate prefixes for the install location and installed libraries location, cross-compilation, non-gcc compilers, non-standard build configurations, etc., etc.). Nevertheless, our CBS is looking good on Linux and both Andrew and I are impressed by its speed. 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Jim D. <ji...@di...> - 2006-08-10 23:48:53
|
"Alan W. Irwin" <ir...@be...> writes: > Here is the current status of our CBS. > > * We need a windows-savvy volunteer to implement the > sys/win32/msdev/src/win3.cpp device driver once bare windows works. > I'll work on that. I've taken a slight pause in plplot work until the CBS work nears completion. > * if CMake works for the djgpp platform (a big if), then Andrew Roach will > undoubtedly want to implement the sys/dos/djgpp/src/gnusvga.c device driver. > > The various non-Linux platforms are beginning to round into shape thanks > to the work of others. > > * On bare windows (visual c++ 2005), Werner tells me that at least the > PLplot core is close to building. The one showstopper was how the math > library was treated, but I think I have now fixed that so I hope it will > build on the next iteration for him. Once that milestone occurs, there will > probably be some considerable extra effort required to expand to other > language interfaces (e.g., python and java), get examples working, etc., but > the bare windows platform is looking quite promising. > > * PLplot has built on Cygwin and MinGW in the past for Werner, but I have > forgotten the completeness of the PLplot language interfaces he was testing, > and how far he tested the examples. > I think it may be prudent to merge the MinGW and the MSDEV versions of the windows driver into one framework. If there are no objections, I can attempt that. -jd |
From: Werner S. <sm...@ia...> - 2006-08-11 06:49:01
|
Hi, > I think it may be prudent to merge the MinGW and the MSDEV versions of > the windows driver into one framework. If there are no objections, I > can attempt that. I also think, that this would make sense - there is no need for two drivers which essentially do the same. But which one is the newer one, or more complete one? Why is the one in cpp and the other only in c? Does it also make sense to move the win3 driver into the driver directory? Regards, Werner -- Werner Smekal email: sm...@ia... phone: +43-(0)676-5014479 |
From: Andrew R. <aro...@ya...> - 2006-08-12 04:31:10
|
I am really playing catch up here, so will join lots of stuff together. At 08:48 AM 11/08/2006 +0200, Werner wrote: >I also think, that this would make sense - there is no need for two >drivers which essentially do the same. But which one is the newer one, wingcc >or more complete one? I'd probably say they are best described as "different". >Why is the one in cpp and the other only in c? Historical=85 win3 was written over a decade ago for windows 3 and was cpp= =20 from the start. wingcc was written about three years ago because: 1) win3=20 would not come even close to compiling under MingW; and, 2) It was cpp and= =20 I wanted to keep the driver purely C to avoid needlessly linking to the cpp= =20 libraries. >Does it also make sense to move the win3 driver into the driver directory? I think that might have implications to the build process used by Visual C,= =20 but again, it is mainly historical, going back to before there was a=20 central build philosophy. At 09:21 AM 11/08/2006 +0200, Werner wrote: >Anyway, MinGW comes in two flavors. >- You can use MinGW just as a compiler in Windows CLI - so you have no >unix like environment. Executables are still win32, and there is no >additional dll, except if you use threads, than mingw1.dll (or so) is >linked to the program - but this dll is not GPL and can also be used in >commercial programs. FWIW I am pretty sure there is a command line option to disable that=20 library and use non-MinGW threading. > > If my understanding is correct, then it should be simple to merge the= two, > > in fact, the existing build system should be usuable in a MinGW shell > > already as it is just a collection of makefiles. > >Yeah, cmake works with both MinGW flavours. The main problem in the past >was (at least I think) that the win32 headers/libraries weren't >complete, so that you couldn't compile programs with MinGW if you used >win32 API. This should be no problem any more, the API is quite stable >and complete. I still run into problems compiling MSDEV stuff under MingW, it is rarely a= =20 show stopper, and usually means making similar changes every time to get=20 the code working, so it isn't a real biggy most of the time=85 but unless it= =20 was (re)written for MingW, I don't think I have ever had something from=20 MSDEV which worked first go without any "intervention". I do not think the= =20 reverse is necessarily true though=85 my observation of the MSDEV code is=20 that it is often needlessly convoluted, and the MingW stuff is usually=20 simpler, but that might just be because I have been using gcc for about 15= =20 years and know the way it works better than Visual C. >Apart from that, also cygwin should be able to compile the wingcc or >win3 driver, since this win32 api can also somehow provided. Agreed. I think an experiment might be to see which driver, win3 or wingcc,= =20 compiles on the most platforms now, and work backwards to the other=20 platform from there. At 01:59 PM 11/08/2006 -0400, Jim wrote: >What I propose is merge similar code from win3.cpp and wingcc.c into >a new file. This new file would not contain any win32 API calls, rather >it would be an abstract plot viewer window--menu bar, event handler, >etc. The second file would contain the win32 API calls that provides >the actions for the first file--get next event, dispatch the event. Unless I am missing something, which I probably am, I think the biggest=20 differences would actually be in the area you nominate as your "abstract=20 plot viewer window"=85 I am not so sure that the differences are that great= =20 in the core API level (stuff liker endering, advancing pages etc=85), more= so=20 the way the win3 driver accesses resources, was built and what not. >The overall layout would be (perhaps collecting the freetype code might >be useful) > >viewer.c > | > +- win32.c > | | > | +- win_gcc.c > | | > | +- win_msdev.c > | > +- freetype.c I am not 100% sure why the freetype is getting spurred off there=85 there is= =20 a minimal amount of code to implement it from the drivers perspective.=20 Ideally, if it were possible, freetype could in theory be replaced with=20 native calls to ExtTextOut() or something similar. That would be a big do=20 though, and probably not worth the time and effort. -Andrew |
From: Jim D. <ji...@di...> - 2006-08-13 03:22:08
|
Andrew Roach <aro...@ya...> writes: > At 01:59 PM 11/08/2006 -0400, Jim wrote: >>What I propose is merge similar code from win3.cpp and wingcc.c into >>a new file. This new file would not contain any win32 API calls, rather >>it would be an abstract plot viewer window--menu bar, event handler, >>etc. The second file would contain the win32 API calls that provides >>the actions for the first file--get next event, dispatch the event. > > Unless I am missing something, which I probably am, I think the biggest > differences would actually be in the area you nominate as your "abstract > plot viewer window" I am not so sure that the differences are that great > in the core API level (stuff liker endering, advancing pages etc), > more so the way the win3 driver accesses resources, was built and what not. > > The "abstract" elements in viewer.c are things like -- The plplot device driver hooks: eop, bop, etc -- The message handling loop -- The layout of the windw I think my proposed win32.c would implement almost everything, however, if there was a significant different that could not be captured within a #define, the code could be placed in win_gcc or win_msdev as needed. >>The overall layout would be (perhaps collecting the freetype code might >>be useful) >> >>viewer.c >> | >> +- win32.c >> | | >> | +- win_gcc.c >> | | >> | +- win_msdev.c >> | >> +- freetype.c > > I am not 100% sure why the freetype is getting spurred off there > there is a minimal amount of code to implement it from the drivers > perspective. Ideally, if it were possible, freetype could in theory > be replaced with native calls to ExtTextOut() or something > similar. That would be a big do though, and probably not worth the > time and effort. > I proposed sticking freetype in its own file because it was an optional entity and clutters the code a little bit. I don't have a strong opinion about it. |
From: Andrew R. <aro...@ya...> - 2006-08-13 05:39:40
|
At 11:21 PM 12/08/2006 -0400, Jim wrote: > > I am not 100% sure why the freetype is getting spurred off there > > there is a minimal amount of code to implement it from the drivers > > perspective. Ideally, if it were possible, freetype could in theory > > be replaced with native calls to ExtTextOut() or something > > similar. That would be a big do though, and probably not worth the > > time and effort. > > > >I proposed sticking freetype in its own file because it was an >optional entity and clutters the code a little bit. I don't have >a strong opinion about it. The freetype code is only about 20 lines (at most). It is a feature of the device API, which is where all the work happens. For a device, all you need do is initialise a couple of flags to let the system know to use it, and add a pointer to a command to set an individual pixel. I think it would prove more bothersome to separate it into another file than keep it integrated. -Andrew |
From: Arjen M. <arj...@wl...> - 2006-08-11 06:49:01
|
Alan W. Irwin wrote: >Here is the current status of our CBS. > >Our CBS is virtually complete. Here are the only exceptions I am aware of. >Only the first of them is relevant on Linux. > >* octave is currently missing from our CBS. That component is similar to >Tcl/Tk with lots of straightforward details so I expect it will take a while >to implement, but I don't expect any serious show-stoppers. Andrew Ross has >kindly volunteered to do the job so he will have the honor of finishing off >our CBS on Linux. > >* The aqt device driver for Mac OS X is a work in progress, but it sounds >like Hazen is close. > >* We need a windows-savvy volunteer to implement the >sys/win32/msdev/src/win3.cpp device driver once bare windows works. > >* if CMake works for the djgpp platform (a big if), then Andrew Roach will >undoubtedly want to implement the sys/dos/djgpp/src/gnusvga.c device driver. > >The various non-Linux platforms are beginning to round into shape thanks >to the work of others. > >* On bare windows (visual c++ 2005), Werner tells me that at least the >PLplot core is close to building. The one showstopper was how the math >library was treated, but I think I have now fixed that so I hope it will >build on the next iteration for him. Once that milestone occurs, there will >probably be some considerable extra effort required to expand to other >language interfaces (e.g., python and java), get examples working, etc., but >the bare windows platform is looking quite promising. > > > As Andy (aendey@..) reported, the PLplot.dll that gets built for bare windows seems to be missing a few wrappers. This means that some examples do not compile. I want to look into that this weekend. And I am having trouble with CMake on Windows, I will report that on the CMake list. >* PLplot has built on Cygwin and MinGW in the past for Werner, but I have >forgotten the completeness of the PLplot language interfaces he was testing, >and how far he tested the examples. > >* As we learned recently from Hazen, PLplot builds okay on Mac except for >python. The examples in the build tree work for C and C++, but there are >some problems with the fortran examples in the build tree and no examples >work yet in the install tree. I expect all these problems are due to minor >Mac OS X linking issues for shared libraries that still have to be worked >out. Or there may be some "obvious" CMake switch that needs to be turned on >for the Mac OS X case. > >Finally, thanks to the efforts of Andrew Ross and yours truly, our CBS is >working reliably on Linux with dynamic device drivers, shared libraries, and >separate build tree. Other variations on that platform need testing (e.g., >static devices, static libraries, source-tree build, separate prefixes for >the install location and installed libraries location, cross-compilation, >non-gcc compilers, non-standard build configurations, etc., etc.). >Nevertheless, our CBS is looking good on Linux and both Andrew and I are >impressed by its speed. > > Hopefully, we will be able to say the same of the Windows platform before long. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-11 07:30:38
|
Hi Arjen, > As Andy (aendey@..) reported, the PLplot.dll that gets built for bare > windows seems > to be missing a few wrappers. This means that some examples do not compile. > I want to look into that this weekend. > > And I am having trouble with CMake on Windows, I will report that on the > CMake list. Just, that I don't work on something which actually already works: Does CBS already work with Visual C++ 200x? My problems so far: 1) isnan/copysign are not known by Visual C++ - need to redefine to _isnan and _copysign (libcsirosa library) in csa.c 2) In the last step the plplotd.dll can't be linked since the csirosa.lib is missing - this file isn't build somehow, the /implib parameter is obviously missing. The 2nd problem I haven't solved yet. Werner -- Werner Smekal email: sm...@ia... phone: +43-(0)676-5014479 |
From: Arjen M. <arj...@wl...> - 2006-08-11 07:04:50
|
Jim Dishaw wrote: >I think it may be prudent to merge the MinGW and the MSDEV versions of >the windows driver into one framework. If there are no objections, I >can attempt that. > > As far as I understand MinGW, it seems much less intrusive than Cygwin, in that it is just another shell. Programs produced in the Cygwin environment seem to rely on Cygwin, so that you can not use them in a regular DOS-box for instance. If my understanding is correct, then it should be simple to merge the two, in fact, the existing build system should be usuable in a MinGW shell already as it is just a collection of makefiles. Could you explain what would need to be done, what such a common framework would look like? Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-11 07:21:39
|
Hi, > As far as I understand MinGW, it seems much less intrusive than Cygwin, > in that it is just another shell. Programs produced in the Cygwin > environment > seem to rely on Cygwin, so that you can not use them in a regular DOS-box > for instance. It's like that: Cygwin provides also the unix environment, so that you can compile unix source with more or less no problems - but it needs a dll (cagwin1.dll), without that no program works - apart from that it's a win32 executable which works everywhere. The problem here is that this dll is GPL - so your program must also be GPL, so cygwin can't be used for closed source or commercial projects (which don't provide the source :). That's the reason cygwin wasn't too much a "success" in the win32 developer community. Anyway, MinGW comes in two flavors. - You can use MinGW just as a compiler in Windows CLI - so you have no unix like environment. Executables are still win32, and there is no additional dll, except if you use threads, than mingw1.dll (or so) is linked to the program - but this dll is not GPL and can also be used in commercial programs. - You can use MinGW als with the MSYS environment (basically a bash), which provides a shell, to which unix users are used to. So you can run configure and so on, and this helps to keep the porting of unix programs to a minimum, as long the code doesn't depend heavily on other libraries. > If my understanding is correct, then it should be simple to merge the two, > in fact, the existing build system should be usuable in a MinGW shell > already as it is just a collection of makefiles. Yeah, cmake works with both MinGW flavours. The main problem in the past was (at least I think) that the win32 headers/libraries weren't complete, so that you couldn't compile programs with MinGW if you used win32 API. This should be no problem any more, the API is quite stable and complete. Apart from that, also cygwin should be able to compile the wingcc or win3 driver, since this win32 api can also somehow provided. Werner -- Werner Smekal email: sm...@ia... phone: +43-(0)676-5014479 |
From: Jim D. <ji...@di...> - 2006-08-11 18:00:19
|
Arjen Markus <arj...@wl...> writes: > Jim Dishaw wrote: > >>I think it may be prudent to merge the MinGW and the MSDEV versions of >>the windows driver into one framework. If there are no objections, I >>can attempt that. >> >> > Could you explain what would need to be done, what such a common > framework would look like? > IIRC the win32 API support between MinGW and the MS development tools were historically different enough that one would not necessairly compile the other. Furthermore, different implementations of the C language specification introduced incompatiblities. Since then things have gotten better. What I propose is merge similar code from win3.cpp and wingcc.c into a new file. This new file would not contain any win32 API calls, rather it would be an abstract plot viewer window--menu bar, event handler, etc. The second file would contain the win32 API calls that provides the actions for the first file--get next event, dispatch the event. If there are differences between msdev and gcc are sufficiently complex for some parts, those portions would go into a third and fouth file. The overall layout would be (perhaps collecting the freetype code might be useful) viewer.c | +- win32.c | | | +- win_gcc.c | | | +- win_msdev.c | +- freetype.c -jd |
From: Arjen M. <arj...@wl...> - 2006-08-11 07:15:17
|
Werner Smekal wrote: >Hi, > > > >>I think it may be prudent to merge the MinGW and the MSDEV versions of >>the windows driver into one framework. If there are no objections, I >>can attempt that. >> >> > >I also think, that this would make sense - there is no need for two >drivers which essentially do the same. But which one is the newer one, >or more complete one? Why is the one in cpp and the other only in c? >Does it also make sense to move the win3 driver into the driver directory? > > Hello Werner, I took Jim's remarks to mean the way one would build stuff under MinGW and bare Windows, you obviously talk of the wingcc and win3 drivers. First: the use of C++ for the win3 driver is historical. As there is very little code that is C++ specific, it should be easy to convert it to C. Second: the existence of two such drivers. This is again at least historical, due to limitations of the available compilers and the platform-specific issues (like the special attributes needed to export functions in DLLs). I would gladly see a merger, but this would mean that the sources can be compiled successfully with both gcc and MSVC/C++ (in all its variations). Currently there is a lot of preprocessor magic going on to keep the MSVC/C++ compiler happy with the various contexts. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-11 07:34:53
|
Hi Arjen, >>> I think it may be prudent to merge the MinGW and the MSDEV versions of >>> the windows driver into one framework. If there are no objections, I >>> can attempt that. >>> >> >> I also think, that this would make sense - there is no need for two >> drivers which essentially do the same. But which one is the newer one, >> or more complete one? Why is the one in cpp and the other only in c? >> Does it also make sense to move the win3 driver into the driver directory? >> > Hello Werner, > > I took Jim's remarks to mean the way one would build stuff under MinGW and > bare Windows, you obviously talk of the wingcc and win3 drivers. ok, I thought that CBS already "solves" that problem, since it provides "native" makefiles for mingw, msdev, borland and watcom compilers. > Second: the existence of two such drivers. This is again at least > historical, > due to limitations of the available compilers and the platform-specific > issues (like the special attributes needed to export functions in DLLs). > I would gladly see a merger, but this would mean that the sources can > be compiled successfully with both gcc and MSVC/C++ (in all its > variations). Currently there is a lot of preprocessor magic going on > to keep the MSVC/C++ compiler happy with the various contexts. So far, I was able with CBS to compile wingcc with gcc and msdev, but could only test the gcc executable since msdev doesn't finish the whole job. So it seems wingcc can be used by both compilers. Werner -- Werner Smekal email: sm...@ia... phone: +43-(0)676-5014479 |
From: Arjen M. <arj...@wl...> - 2006-08-11 09:55:50
|
Alan W. Irwin wrote: >Here is the current status of our CBS. > > > Here are some findings of using the CBS on bare Windows: - I used the latest PLplot sources (fresh checkout) - I used the latest CMake sources (because of a problem Bill Hoffman solved in the recognition of Fortran) I ran CMake with: cmake -G "Nmake makefiles" . (I made sure it can find the MSVC/C++ 6.0 compiler by running vcvars32.bat) - CMake claims that the Fortran compiler does not support F90/F95. Odd, but that is not a real problem ATM - CMake seems to search for libgdi32.a - that may just the message text though. It found both windows.h and libgdi32.a and is happy. - It completed the generation of the source files. Now I am going to see whether PLplot is indeed built. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-11 10:07:53
|
Hi Arjen, > Here are some findings of using the CBS on bare Windows: > - I used the latest PLplot sources (fresh checkout) > - I used the latest CMake sources (because of a problem Bill Hoffman > solved in the recognition of Fortran) > > I ran CMake with: > > cmake -G "Nmake makefiles" . > > (I made sure it can find the MSVC/C++ 6.0 compiler by running vcvars32.bat) > > - CMake claims that the Fortran compiler does not support F90/F95. Odd, but > that is not a real problem ATM > - CMake seems to search for libgdi32.a - that may just the message text > though. Yes, that's just the message, cmake takes care, that in this case it looks for gdi32.lib, we should change the message though. It's interesting though that it found gdi32.lib, since it actually shouldn't right now, at least vor Visual C++ 2005 I had to change FindGDI32.cmake to find_library( GDI32_LIBRARY NAMES gdi32 PATHS ${GDI32_LIBRARY_DIRS} $ENV(LIB) NO_SYSTEM_ENVIRONMENT_PATH ) Since vcvars32.bat sets the LIB environment variable to a path, where gdi32.lib can be found > It found both windows.h and libgdi32.a and is happy. > - It completed the generation of the source files. > > Now I am going to see whether PLplot is indeed built. I'm interested too :) Werner |
From: Alan W. I. <ir...@be...> - 2006-08-11 19:15:45
|
On 2006-08-11 13:59-0400 Jim Dishaw wrote: > What I propose is merge similar code from win3.cpp and wingcc.c into > a new file. I don't have an opinion one way or the other about this. However, since Andrew Roach wrote wingcc.c and is one of our more prolific device driver writers, I strongly encourage him to get involved in this discussion at the planning stage. 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2006-08-12 14:09:27
|
On 2006-08-11 11:55+0200 Arjen Markus wrote: > Here are some findings of using the CBS on bare Windows: > [...] > It found both windows.h and libgdi32.a and is happy. > - It completed the generation of the source files. > > Now I am going to see whether PLplot is indeed built. Arjen, you have a wonderful dramatic touch leaving us all in suspense waiting for your next e-mail. :-) 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2006-08-12 19:55:33
|
> On 2006-08-11 11:55+0200 Arjen Markus wrote: > >> Here are some findings of using the CBS on bare Windows: >> [...] >> It found both windows.h and libgdi32.a and is happy. >> - It completed the generation of the source files. >> >> Now I am going to see whether PLplot is indeed built. > > Arjen, you have a wonderful dramatic touch leaving us all in suspense > waiting for your next e-mail. :-) > Hi Alan, well, that was quite unintentional! I did send a follow-up only minutes after that - and I distinctly received it myself ... but then, I may not have sent it to everyone, just myself :( (That explains Werner's reply!) Oh dear, and here I was waiting for your answers! Okay, short story: It did not compile - compiling the tk.c source failed. That was yesterday (and I asked for information on how to turn Tk off). Today I tried to solve that puzzle myself and that is the long, not yet ended story: 1. Turning Tk off turned out to be easy - just edit the parameter in the CMakeCache.txt file. 2. This led to syntax errors in wingcc.c: the Verbose(...) and Debug(...) macros were not accepted by MSVC/C++ 6.0. I commented them out 3. Then the building of the plplotd.dll library failed. An unresolved external in wingcc.obj. I turned off wingcc as well. 4. plplotd.dll got built, but now there was a message about "cat" being an unknown command. Still, the library was built, so I went on to build the examples. 5. This led to complaints about mktclIndex being an unknown command So, to keep it simple, I turned off Tcl as well. 6. Reconfiguring and rebuilding plplotd.dll with Tcl turned off revealed problems in the building of the cxx library: no plplotd.lib. The error about cat had prevented that step before). And that reminded me of Werner's problem with plplotd.lib and now I realise what is going wrong: There are exported symbols, according to the compiler, and therefore there is no need to build an import library (which is what plplotd.lib is). Okay, the solution is this: 1. For the moment we can force CMake to create makefiles that build static libraries. Then we have no trouble with exporting the various functions. 2. We adopt the method used for the win3 device - call the actual C functions via a "stub" (see sys/win32/msdev/plstub.cpp). I am going to see about the first method. That seems easy enough (the second involves a lot of preprocessor magic, and it is too late in the evening to dive into that). Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2006-08-12 20:11:36
|
> > Okay, the solution is this: > > 1. For the moment we can force CMake to create makefiles that build > static libraries. Then we have no trouble with exporting the > various functions. > 2. We adopt the method used for the win3 device - call the actual > C functions via a "stub" (see sys/win32/msdev/plstub.cpp). > > I am going to see about the first method. That seems easy enough > (the second involves a lot of preprocessor magic, and it is too > late in the evening to dive into that). > Well, there seems to be no option to force static libraries, so I edited the makefile instead. That did get me to build a static library, but then the next problem surfaced: no examples will actually get built. The makefiles do not contain any rules for creating the examples. Trying to build at least one example manually was unsuccessful - the linker complained about all sorts of unresolved externals (sigh). This will have to wait until tomorrow. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2006-08-13 00:16:31
|
On 2006-08-12 22:11+0200 Arjen Markus wrote: > >> >> Okay, the solution is this: >> >> 1. For the moment we can force CMake to create makefiles that build >> static libraries. Then we have no trouble with exporting the >> various functions. >> 2. We adopt the method used for the win3 device - call the actual >> C functions via a "stub" (see sys/win32/msdev/plstub.cpp). >> >> I am going to see about the first method. That seems easy enough >> (the second involves a lot of preprocessor magic, and it is too >> late in the evening to dive into that). >> > > Well, there seems to be no option to force static libraries,... I just put one in. It is called BUILD_SHARED_LIBS with a default of ON. If you turn it OFF you get static libraries instead. In some ways static libraries are more complicated than shared because you have to place the device driver code into libplplotd and make sure all the extra compiler and library flags associated with the devices is all incorporated into the compiler and library flags for libplplot. All the infrastructure is in place to do that, but it is largely untested. I just tested static libraries for the combination of DEFAULT_NO_DEVICES ON and PLD_ps ON options (which gives you _just_ the ps device to keep things simple). That turned up bugs in the way that plplot(d).pc (the file controlling pkg-config results for libplplot(d)) was configured which I have just fixed in CVS. For this early debugging stage for the bare windows case, I suggest you use just the ps device to start with also. 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); PLplot scientific plotting software package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2006-08-13 05:43:04
|
> On 2006-08-12 22:11+0200 Arjen Markus wrote: > > > I just put one in. It is called BUILD_SHARED_LIBS with a default of > ON. If you turn it OFF you get static libraries instead. > > In some ways static libraries are more complicated than shared because > you have to place the device driver code into libplplotd and make sure > all the extra compiler and library flags associated with the devices is > all incorporated into the compiler and library flags for libplplot. > All the infrastructure is in place to do that, but it is largely > untested. > > I just tested static libraries for the combination of > DEFAULT_NO_DEVICES ON and PLD_ps ON options (which gives you _just_ the > ps device to keep things simple). That turned up bugs in the way that > plplot(d).pc (the file controlling pkg-config results for libplplot(d)) > was configured which I have just fixed in CVS. > > For this early debugging stage for the bare windows case, I suggest you > use just the ps device to start with also. > Okay, I just did so: As I can not use the CMake version for Windows with its GUI, I am using the command-line version I built from the sources (from the CVS repository from friday). The command-line options are: -DBUILD_SHARED_LIBS:BOOL=OFF -DDEFAULT_NO_DEVICES:BOOL=ON -DPLD_ps:BOOL=ON This builds the static libraries without any complaints, only there is a problem with the Fortran 90/95 build - the compiler is not recognising the options. (Probably a numbert of language bindings were turned off via the cache). Still, no examples are built, as the makefiles contain no instructions for building them. Re: isnan and CSA I have seen no problems with _isnan() and such because building the CSA library is turned off. I know the reason for the underscore: There is a convention that non-standard system functions get an underscore in front of the name (IIRC, that is an ISO-C standard). So, on Windows you have to use _putenv(), _isnan(), ... On UNIX the names without the underscores already existed before the ISO-C standard of course. Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2006-08-13 06:01:01
|
After the exercise with bare Windows, I thought I'd try with Cygwin. The results are promising at least: - Because the build system could not find "tclgen.h" and "tclgen_s.h", I turned off Tcl/Tk. That did the trick in building the various libraries. - There was a warning that wingcc was disabled - no idea why - The examples still can not be built, though there is a Makefile.examples file. I uncommented the lines for actually building the C programs, but pkg-config is missing. So, that is the status for Cygwin at the moment. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2006-08-13 08:15:38
Attachments:
FindGDI32.c
FindGDI32.cmake
|
> - There was a warning that wingcc was disabled - no idea why Because FindGDI32.cmake looks for windows.h and than for the library gdi32, which is provided by MinGW (win32.api) and Visual C++ logically, and also by cygwin, but the way it finds the header and linker is far from perfect in the moment. I rewrote them, to try to compile a test program which includes windows.h and needs gdi32 to compile - this works for cygwin and mingw but not for Visual C++ in the moment. Files attached, put them in cmake/modules. This makes much more sense, since windows compilers have them normally in their standard paths - so instead of try to find them, just test if it is correctly set up. > - The examples still can not be built, though there is a Makefile.examples > file. I uncommented the lines for actually building the C programs, > but pkg-config is missing. You need to install pkg-config. cygwin provides version 0.20-1 - then it should work. > > So, that is the status for Cygwin at the moment. regards, Werner |
From: Werner S. <sm...@ia...> - 2006-08-13 07:51:23
|
> Still, no examples are built, as the makefiles contain no instructions > for building them. The reason for that is that you don't have pkg-config installed - actually cmake should mention during it runs, that it doesn't find pkg-config and that it turns of example building. At least I get for Visual C++ 2005: -- Looking for pkg-config -- Looking for pkg-config - not found -- WARNING: Build of examples will not work. > > Re: isnan and CSA > I have seen no problems with _isnan() and such because building the CSA > library is turned off. I know the reason for the underscore: > There is a convention that non-standard system functions get an underscore > in front of the name (IIRC, that is an ISO-C standard). So, on Windows > you have to use _putenv(), _isnan(), ... On UNIX the names without the > underscores already existed before the ISO-C standard of course. I think that when cmake looks for isnan it should also look for _isnan and set some defines. Later in the csa.c code we could add at the beginning #ifdef _HAVE_UNDERSCORE_ISNAN #undef isnan #define isnan(x) _isnan(x) #undef copysign #define copysign(x,y) _copysign(x,y) #endif or something like that. This makes csa.c compile for me, we could also put it between #ifdef MSDEV or so, but than we didn't check if its there - and we have cmake for that, or? Werner > > Regards, > > Arjen > > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: <hba...@ma...> - 2006-08-13 16:10:17
|
On Aug 12, 2006, at 8:15 PM, Alan W. Irwin wrote: > > I just tested static libraries for the combination of > DEFAULT_NO_DEVICES ON > and PLD_ps ON options (which gives you _just_ the ps device to keep > things > simple). That turned up bugs in the way that plplot(d).pc (the file > controlling pkg-config results for libplplot(d)) was configured > which I have > just fixed in CVS. Thanks! This also fixed the problem I was having with plplotd.pc on OS-X. -Hazen |