From: Alan W. I. <ir...@be...> - 2007-02-28 00:26:40
|
I am pretty satisfied with the CMake build system improvements I have just checked in to substantially refine how we deal with the Ada interface and examples. Here is what I have done. * I have implemented a limited Ada language support for CMake. As a result of this effort, add_library should now work cross-platform, but add_executable is not available since it needs a change to the core of CMake to do the required gnatbind and gnatlink. * I have substantially refined the configuration and taken advantage of the new Ada language support so that the build of libplplotada and the build of the example (still done with a custom rule rather than add_executable because of above limitation in the language support ) should "just work" cross-platform. Caveats: * GNAT compiler package has to be installed (e.g., gnat-4.0 package on Ubuntu Dapper). GNAT is an add-on package for gcc so you must ensure that the version of GNAT that you install is consistent with the gcc version that you have installed. * ENABLE_ada is OFF by default (and we should continue with that default until this interface gets a lot more testing) so must use -DENABLE_ada=ON cmake option to build the libplplotada library. * On really old systems (e.g., Debian stable but not Ubuntu Dapper) it is difficult to find libgnat so you may have to set, e.g., export CMAKE_LIBRARY_PATH=/usr/lib/gcc-lib/i486-linux/3.3.5/adalib to give CMake a strong hint where to find libgnat. * Must use -DBUILD_TEST=ON cmake option so that the "make" command in the build tree builds the ada example. * Must set, e.g., the following environment variables to run the example that was built in the build tree (these have to be set for any example in the build tree, but normally you don't have to worry about this because ctest takes care of it for you): export EXAMPLES_DIR=/home/software/plplot_cvs/HEAD/build_dir/examples export SRC_EXAMPLES_DIR=/home/software/plplot_cvs/HEAD/build_dir/../plplot_cmake/examples export PLPLOT_LIB=/home/software/plplot_cvs/HEAD/build_dir/../plplot_cmake/data Once those caveats are satisfied, then from the top-level of the build tree ldd -r bindings/ada/libplplotadad.so and ldd -r examples/ada/ada_plplot give good results after the "cmake" and "make" commands are executed showing all libraries have been properly found and all symbols resolved. Furthermore, examples/ada/ada_plplot -dev whatever gives good results (so far on Debian stable and Ubuntu Dapper). ToDo: (1) Lots of testing on a variety of platforms. Jerry (and other interested developers), please give it a try, and let me know whether everything works well on your platform of choice. (2) Set up ctest so that the ada example will be executed as a result of the ctest command. This refinement is not essential for testing so long as you remember to set the EXAMPLES_DIR, SRC_EXAMPLES_DIR, and PLPLOT_LIB environment variables to the proper locations for everything. (3) Fill in the rest of the standard examples implemented in Ada. (4) Once a substantial number of standard examples have been implemented and this Ada binding has substantially matured, configure the install. The big question there is where to install libplplotada and its accompanying Ada source files and *.ali files. (N.B. Ada libraries usually have their own directory filled with the library and the source files [at least the spec files but possibly body files as well] and *.ali files.) I will take responsibility for (2) fairly soon, and (4) in the "fullness of time". I may chip in with some help on (3) as well once the pattern of how you program in Ada has been established by the implementation of a few more standard examples. 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...> - 2007-02-28 07:51:39
|
Alan W. Irwin wrote: >I am pretty satisfied with the CMake build system improvements I have just >checked in to substantially refine how we deal with the Ada interface and >examples. Here is what I have done. > > > Hello Alan, Jerry, I think you two are doing a wonderful job: adding a completely new language to the project is not a sinecure. It also goes to show that the decision to use CMake was a good one. I am not sure when I will have time to try this on Cygwin (I do not use Ada, nor am I at all familiar with gnat and compiling and linking Ada programs, so this would be all new to me), but I will try to do it. Regards, Arjen |
From: Werner S. <sm...@ia...> - 2007-02-28 07:56:03
|
Hi, I already added gnat to my MinGW tools, so I'll post results for this toolchain soon. thanks for the efforts, Werner Arjen Markus wrote: > Alan W. Irwin wrote: > >> I am pretty satisfied with the CMake build system improvements I have just >> checked in to substantially refine how we deal with the Ada interface and >> examples. Here is what I have done. >> >> >> > Hello Alan, Jerry, > > I think you two are doing a wonderful job: adding a completely new > language to > the project is not a sinecure. It also goes to show that the decision to > use CMake > was a good one. > > I am not sure when I will have time to try this on Cygwin (I do not use Ada, > nor am I at all familiar with gnat and compiling and linking Ada programs, > so this would be all new to me), but I will try to do it. > > Regards, > > Arjen > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2007-02-28 20:12:16
|
On 2007-02-27 16:25-0800 Alan W. Irwin wrote: > I am pretty satisfied with the CMake build system improvements I have just > checked in to substantially refine how we deal with the Ada interface and > examples. Here is what I have done. > > * I have implemented a limited Ada language support for CMake. As a result > of this effort, add_library should now work cross-platform, but > add_executable is not available since it needs a change to the core of CMake > to do the required gnatbind and gnatlink. Thanks to an idea by Bill Hoffman (a most helpful CMake guru on the CMake mailing list), I now have a working add_executable for the Ada language. There are some constraints on its use, but fundamentally it works (see the revised examples/ada/CMakeLists.txt which is much simpler than the previous custom rule). Note, there was a period of about two hours this morning when -DENABLE_ada=ON gave cmake errors for the CVS version of PLplot, but all should be well now. 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...> - 2007-03-01 01:15:58
|
On 2007-02-27 16:25-0800 Alan W. Irwin wrote: > ToDo: > > (2) Set up ctest so that the ada example will be executed as a result of the > ctest command. This refinement is not essential for testing so long as you > remember to set the EXAMPLES_DIR, SRC_EXAMPLES_DIR, and PLPLOT_LIB > environment variables to the proper locations for everything. Done. > (3) Fill in the rest of the standard examples implemented in Ada. I added the standard example 10 just to see if I was now an expert Ada programmer. The answer is probably not... :-) N.B. I have renamed the previous ada_plplot.adb to x01a.adb (the main routine that withs in x01.ad?), and the new standard example is contained in the files x10a.adb, x10.adb, and x10.ads. Jerry, to do build-tree tests of the Ada interface (after "make" is executed) for the two examples in CVS now all you have to do is type ctest --tests-regex ada The resulting test/x01a.ps was identical to test/x01c.ps (generated with a prior run) verifying at least the "thick" Ada interface API exercised in this test is fine. However, x10c.ps was not identical to x10c.ps. In the Ada result the plot boxes are made with tick marks that should not be there according to the xopt and yopt command strings "bc". Jerry, could you please look at the new example 10? I wrote it almost entirely in the thin interface. I notice that the C version of plbox is called by Box_Around_Viewport in the thick interface in a different way then the thin interface plbox Ada routine calls the C version so there may be a systematic thin API problem that is revealed by this example. Also, I think it is important to emphasize the parallel nature of the standard examples for every language so I strongly prefer that we provide thin interface (e.g., plbox rather than Box_Around_Viewport) standard examples. That, of course, does not preclude additional examples written in the thick interface with the more descriptive names for the API. Also, could you provide plparseopts in the thin interface? Virtually every language interface has plparseopts defined (normally with just one argument). That would have allowed me to write x10.adb completely in the thin interface. 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: Jerry <lan...@qw...> - 2007-03-01 02:34:20
|
I'll look into the plparseopts situation. Also, with the examples, the former ada_plplot.adb is just a high- level driver to run all of the examples as they become available--it is not necessary if the examples are kept as stand-alone programs. So--I recommend just renaming all the example files to x??a.adb and letting them run as standalones, and eliminating the x??.adb and x??.ads naming level completely. That was my intention originally but I see that I forgot to adopt that naming convention. I can take care of this. Jerry On Feb 28, 2007, at 6:14 PM, Alan W. Irwin wrote: > On 2007-02-27 16:25-0800 Alan W. Irwin wrote: > >> ToDo: >> >> (2) Set up ctest so that the ada example will be executed as a >> result of the >> ctest command. This refinement is not essential for testing so >> long as you >> remember to set the EXAMPLES_DIR, SRC_EXAMPLES_DIR, and PLPLOT_LIB >> environment variables to the proper locations for everything. > > Done. > >> (3) Fill in the rest of the standard examples implemented in Ada. > > I added the standard example 10 just to see if I was now an expert Ada > programmer. The answer is probably not... :-) > > N.B. I have renamed the previous ada_plplot.adb to x01a.adb (the main > routine that withs in x01.ad?), and the new standard example is > contained in > the files x10a.adb, x10.adb, and x10.ads. > > Jerry, to do build-tree tests of the Ada interface (after "make" is > executed) for the two examples in CVS now all you have to do is type > > ctest --tests-regex ada > > The resulting test/x01a.ps was identical to test/x01c.ps (generated > with a > prior run) verifying at least the "thick" Ada interface API > exercised in > this test is fine. However, x10c.ps was not identical to x10c.ps. > In the > Ada result the plot boxes are made with tick marks that should not > be there > according to the xopt and yopt command strings "bc". > > Jerry, could you please look at the new example 10? I wrote it almost > entirely in the thin interface. I notice that the C version of > plbox is > called by Box_Around_Viewport in the thick interface in a different > way then > the thin interface plbox Ada routine calls the C version so there > may be a > systematic thin API problem that is revealed by this example. > > Also, I think it is important to emphasize the parallel nature of the > standard examples for every language so I strongly prefer that we > provide > thin interface (e.g., plbox rather than Box_Around_Viewport) standard > examples. That, of course, does not preclude additional examples > written in > the thick interface with the more descriptive names for the API. > > Also, could you provide plparseopts in the thin interface? > Virtually every > language interface has plparseopts defined (normally with just one > argument). > That would have allowed me to write x10.adb completely in the thin > interface. > > Alan > __________________________ |
From: Jerry <lan...@qw...> - 2007-03-11 07:12:41
|
On Feb 28, 2007, at 6:14 PM, Alan W. Irwin wrote: > Also, could you provide plparseopts in the thin interface? > Virtually every > language interface has plparseopts defined (normally with just one > argument). > That would have allowed me to write x10.adb completely in the thin > interface. Before I started to make the change by adding plparseopts to the thin binding, just for kicks I tried to run an example using command line arguments. (I usually don't supply any in my normal testing, but I have tried it in the past to make sure that the command parsing was working, which it was.) So I've discovered that when using the 5.7.2 libraries, a bus error was generated with this call stack (ada_42 is the main program): #0 0x901316e0 in memcmp #1 0x907f280c in __CFInitialize #2 0x9083753c in __CFSetupFoundationBridging #3 0x929cc4f4 in _NSToDoAtProcessStart #4 0x9293ca60 in _NSInitializePlatform #5 0x90a40548 in call_class_loads #6 0x90a4045c in call_load_methods #7 0x90a3b2c8 in map_images #8 0x8fe0f3c0 in __dyld__ZN16ImageLoaderMachO14doNotificationE15dyld_image_modejPK15dyld_ image_info #9 0x8fe035a8 in __dyld__ZN4dyld12notifyAddingERSt6vectorIP11ImageLoaderSaIS2_EE #10 0x8fe0da94 in __dyld__ZN11ImageLoader4linkERKNS_11LinkContextENS_15BindingLazinessENS_ 18InitializerRunningEj #11 0x8fe04054 in __dyld__ZN4dyld4linkEP11ImageLoaderNS0_15BindingLazinessENS0_18Initializ erRunningE #12 0x8fe0992c in __dyld_dlopen #13 0x900308f4 in dlopen #14 0x96a472f8 in sys_dl_open #15 0x96a47d70 in tryall_dlopen #16 0x96a4b0e0 in try_dlopen #17 0x96a4b4c0 in lt_dlopenext #18 0x0016fd70 in plLoadDriver #19 0x0016eac8 in pllib_devinit #20 0x0016cf3c in c_plinit #21 0x00032e50 in plplot.initialize_plplot at plplot.adb:1615 #22 0x0001f3e4 in plplot.initialize_plotter at plplot.adb:34 #23 0x000420fc in testing_thick_binding.main_testing_thick_binding at testing_thick_binding.adb:74 #24 0x000490d0 in ada_42 at ada_42.adb:19 Using the same Ada sources but linking instead the old 5.5.3 libraries, there is no crash and the commands are parsed correctly. (One qualifier--to run the old libraries I have to edit the thin binding so that c_plmeridians and c_plmap either do or do not have the leading c_, but I hardly think this is the problem.) The last few calls in the call stack seem to be OS X calls, as NSxxx is a very common OS X symbol (stands for Next Step--why change it if it's not broken, right?) and CFxxx probably stands for Core Foundation, another OS X name convention. When there are no command line args, the program runs normally. Any ideas? Jerry |
From: Alan W. I. <ir...@be...> - 2007-03-01 17:44:36
|
On 2007-02-28 19:34-0700 Jerry wrote: > So--I recommend just renaming all the example files to x??a.adb and > letting them run as standalones, and eliminating the x??.adb and > x??.ads naming level completely. That was my intention originally but > I see that I forgot to adopt that naming convention. I can take care > of this. Hi Jerry: I have just tried this, but it does not work for me. gnatmake compiles x01.adb without problems, but it did not bind or link it. (I tried this experiment for the original source code you sent me before the reorganization that occurred in the CVS version just to be sure the problem was not an artifact of that reorganization) irwin@chickadee> gnatmake x01.adb gcc-3.3 -c x01.adb gcc-3.3 -c plplot.adb gcc-3.3 -c plplotthin.adb If I attempt to force it with the -b option, gnatmake generates the following error message: irwin@chickadee> gnatmake -b x01.adb gnatbind -x x01.ali error: "x01.ali" does not contain a unit that can be a main program gnatmake: *** bind failed. You should be able to easily verify this problem for yourself. If there is some simple change that can be made to x01.adb so that it is suitable for a main program please send it to me. I too would prefer to eliminate the separate driver programme for each example if that is possible. Two files per example is preferred to three files per example. 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...> - 2007-03-01 20:19:03
|
On 2007-03-01 09:40-0800 Alan W. Irwin wrote: > On 2007-02-28 19:34-0700 Jerry wrote: > >> So--I recommend just renaming all the example files to x??a.adb and >> letting them run as standalones, and eliminating the x??.adb and >> x??.ads naming level completely. That was my intention originally but >> I see that I forgot to adopt that naming convention. I can take care >> of this. > > Hi Jerry: > > I have just tried this, but it does not work for me. gnatmake compiles > x01.adb without problems, but it did not bind or link it. > [...]Two files per example is preferred to three files per example. Hi Jerry: Never mind, I figured it out. (I had to remove the package body statements from the standalone versions). A side benefit is a spec file is not needed. Thus, we are now reduced to one standalone source file (x??a.adb) per example. I just committed all my changes to CVS. ctest --tests-regex ada works without run-time errors and creates postscript results (x01a.ps and x10a.ps) in the test subdirectory. x01a.ps is identical to x01c.ps (the equivalent C result) and similarly for x10a.ps and x10c.ps. However, that was because I replaced - plbox("bc", 0.0, 0, "bc", 0.0, 0); + Box_Around_Viewport(TUB("bc"), 0.0, 0, TUB("bc"), 0.0, 0); If I use plbox rather than Box_Around_Viewport, then the result has extraneous tick marks. I don't understand the cause of this problem. The same example has a call to plptex with another character array, and that works without problems. I have also carefully compared how plptex and plbox are set up in plplotthin.ads, and I cannot spot anything. I also tried the TUB("bc") in the argument list for plbox, but the compiler complained about something being inconsistent before erroring out so I dropped it. This marks the end of the initial intense phase of my getting Ada supported under CMake for PLplot. We have made a good start, and the way forward is clear. * All developers should check the Ada aspects of the CMake build system on their platform of choice. Simply install the gnat extension to gcc (the gnat-4.0 package does this on Ubuntu Dapper), use the -DENABLE_ada and -DBUILD_TEST=ON cmake options, and run "ctest --tests-regex ada" after the make command. * Jerry needs to sort out the existing issues (plparseopts and plbox) with the thin API before we move forward with filling in the rest of the standard examples in the thin API (which may well turn up other API issues). 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: Werner S. <sm...@ia...> - 2007-03-03 16:26:23
|
Hi Alan, I'm just testing the ada bindings with MinGW but there are some problems. So far I solved the following ones: 1) gnat library is not found - we need to set CMAKE_LIBRARY_PATH: rem setup ada set CMAKE_LIBRARY_PATH=%MINGWDIR%\lib\gcc\mingw32\3.4.5\adalib;%CMAKE_LIBRARY_PATH% where MINGWDIR is the path to the MinGW installation. 2) gnatgcc doesn't exist - in Windows this is gcc! In "CMakeDetermineAdaCompiler.cmake" change line 33 to SET(CMAKE_Ada_COMPILER_LIST gnatgcc gcc) though I don't think that that is the correct way to do it - don't know if Linux/Mac OSX gcc knows how to handle ada files. Don't know why Windows gcc knows it. Than cmake configures happily, but we encounter problems while compiling: [ 45%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.obj C:\DevZone\MinGW-3.4.5\bin\gcc.exe -Dplplotadad_EXPORTS -DHAVE_CONFIG_H -o bindings/ada/CMakeFiles/plplotadad.dir/plplot.obj -c Z:\DevZone\PLdev\plplot\bindings\ada\plplot.adb gnat1: incorrect object file extension Argh, gnat1 wants to have .o as ending instead of .obj though the latter one is Windows style. If I run the last command and change plplot.obj to plplot.o it compiles! I need to copy it to obj, than cmake accepts it and continues but than the same with the thin library. Change command to .o by hand, compile, copy it. Than library builds. First example, same problem. Change, compile, copy. But than: gnatmake: "x01a.exe.adb" not found so the extension is a problem. Ok, this gets now a little tedious - I actually don't know how to fix the .obj/.o problem. This is set by cmake, but mingw-gnat obviously is buggy here. And than it seems the .exe is in <TARGET>, which you use, Alan, instead of <SOURCE> or so, if I followed your posts to the CMake List correctly. So, any help would be appreciated. - Werner Alan W. Irwin wrote: > On 2007-03-01 09:40-0800 Alan W. Irwin wrote: > >> On 2007-02-28 19:34-0700 Jerry wrote: >> >>> So--I recommend just renaming all the example files to x??a.adb and >>> letting them run as standalones, and eliminating the x??.adb and >>> x??.ads naming level completely. That was my intention originally but >>> I see that I forgot to adopt that naming convention. I can take care >>> of this. >> Hi Jerry: >> -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Jerry <lan...@qw...> - 2007-03-02 01:53:43
|
On Mar 1, 2007, at 1:18 PM, Alan W. Irwin wrote: > On 2007-03-01 09:40-0800 Alan W. Irwin wrote: > >> On 2007-02-28 19:34-0700 Jerry wrote: >> >>> So--I recommend just renaming all the example files to x??a.adb and >>> letting them run as standalones, and eliminating the x??.adb and >>> x??.ads naming level completely. That was my intention originally >>> but >>> I see that I forgot to adopt that naming convention. I can take care >>> of this. >> >> Hi Jerry: >> >> I have just tried this, but it does not work for me. gnatmake >> compiles >> x01.adb without problems, but it did not bind or link it. >> [...]Two files per example is preferred to three files per example. > > Hi Jerry: > > Never mind, I figured it out. (I had to remove the package body > statements > from the standalone versions). A side benefit is a spec file is not > needed. > Thus, we are now reduced to one standalone source file (x??a.adb) per > example. I just committed all my changes to CVS. Yes--sorry for my slow response. You are now an expert Ada programmer 8^). > > * Jerry needs to sort out the existing issues (plparseopts and > plbox) with > the thin API before we move forward with filling in the rest of the > standard > examples in the thin API (which may well turn up other API issues). > OK. Jerry |
From: Werner S. <sm...@ia...> - 2007-03-03 10:31:07
|
Hi Jerry and Alan, I tested both ada examples with Kubuntu Edgy Eft and it worked flawlessy (this was to be expected since Alan tested it on Ubuntu already). Hopefully soon I can test it on MinGW. Lot to do in the moment, and using Latex is so much faster in Linux than in Windows, so that's the reason I mostly boot Linux now ;) Regards, Werner Jerry wrote: > On Mar 1, 2007, at 1:18 PM, Alan W. Irwin wrote: > > >> On 2007-03-01 09:40-0800 Alan W. Irwin wrote: >> >> >>> On 2007-02-28 19:34-0700 Jerry wrote: >>> >>> >>>> So--I recommend just renaming all the example files to x??a.adb and >>>> letting them run as standalones, and eliminating the x??.adb and >>>> x??.ads naming level completely. That was my intention originally >>>> but >>>> I see that I forgot to adopt that naming convention. I can take care >>>> of this. >>>> >>> Hi Jerry: >>> >>> I have just tried this, but it does not work for me. gnatmake >>> compiles >>> x01.adb without problems, but it did not bind or link it. >>> [...]Two files per example is preferred to three files per example. >>> >> Hi Jerry: >> >> Never mind, I figured it out. (I had to remove the package body >> statements >> from the standalone versions). A side benefit is a spec file is not >> needed. >> Thus, we are now reduced to one standalone source file (x??a.adb) per >> example. I just committed all my changes to CVS. >> > > Yes--sorry for my slow response. You are now an expert Ada programmer > 8^). > > >> * Jerry needs to sort out the existing issues (plparseopts and >> plbox) with >> the thin API before we move forward with filling in the rest of the >> standard >> examples in the thin API (which may well turn up other API issues). >> >> > OK. > > Jerry > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2007-03-03 19:23:50
|
Hi Werner: On 2007-03-03 17:25+0100 Werner Smekal wrote: > Hi Alan, > > I'm just testing the ada bindings with MinGW but there are some problems. So > far I solved the following ones: > > 1) gnat library is not found - we need to set CMAKE_LIBRARY_PATH: > > rem setup ada > set > CMAKE_LIBRARY_PATH=%MINGWDIR%\lib\gcc\mingw32\3.4.5\adalib;%CMAKE_LIBRARY_PATH% > > where MINGWDIR is the path to the MinGW installation. > > 2) gnatgcc doesn't exist - in Windows this is gcc! In > "CMakeDetermineAdaCompiler.cmake" change line 33 to > > SET(CMAKE_Ada_COMPILER_LIST gnatgcc gcc) > > though I don't think that that is the correct way to do it - don't know if > Linux/Mac OSX gcc knows how to handle ada files. Don't know why Windows gcc > knows it. gnat is an extension to gcc, but it seems to be implemented differently than other extensions such as g77. For example, gnatgcc (on Linux systems at least) is simply a symlink to a generic versioned form of gcc while g77 is symlinked to a versioned form of a g77 executable. OTOH, I know that gnat is definitely something more than just gcc alone. Perhaps the solution is to use gnatmake to wrap compilations. I will see whether I can arrange that. > > Than cmake configures happily, but we encounter problems while compiling: > > [ 45%] Building Ada object bindings/ada/CMakeFiles/plplotadad.dir/plplot.obj > C:\DevZone\MinGW-3.4.5\bin\gcc.exe -Dplplotadad_EXPORTS -DHAVE_CONFIG_H -o > bindings/ada/CMakeFiles/plplotadad.dir/plplot.obj -c > Z:\DevZone\PLdev\plplot\bindings\ada\plplot.adb > gnat1: incorrect object file extension > > Argh, gnat1 wants to have .o as ending instead of .obj though the latter one > is Windows style. If I run the last command and change plplot.obj to plplot.o > it compiles! I need to copy it to obj, than cmake accepts it and continues > but than the same with the thin library. Change command to .o by hand, > compile, copy it. Than library builds. That's a surprising result. What happens for the equivalent PLplot C core library build? I assume the extensions for the -o option will be .obj (like above), that gcc will build those objects without complaint, and in the next step (doing the special linking with gcc to create the shared library) gcc will happily link the *.obj files into the shared library. So I have to ask (rhetorically) what is causing problems with the .obj suffix for the Ada case? Possibly it's a matter of using the correct compilation options for gcc. It's possible those will automatically be generated if I use gnatmake to wrap the compilation (see above). Of course, gnatmake doesn't know how to create libraries so gcc must always be used for the special linking step that creates the shared library. > > gnatmake: "x01a.exe.adb" not found > > so the extension is a problem. I was afraid of that. There are several possibilities for fixing this, but lets wait to try those out until after I have done some experiments with wrapping the compilations with gnatmake to see if that solves the *.obj suffix problems. Thanks for your report. 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: Werner S. <sm...@ia...> - 2007-03-03 20:18:51
|
Hi Alan, > That's a surprising result. What happens for the equivalent PLplot C core > library build? I assume the extensions for the -o option will be .obj (like > above), that gcc will build those objects without complaint, and in the next > step (doing the special linking with gcc to create the shared library) gcc > will happily link the *.obj files into the shared library. Yes, gcc has actually no problems with the .obj extension. But gcc seems to call gnat1 to compile the ada file and though I found a description of gnat for Windows, where it is explained that the -o option should be used to set the output filename with the ending .obj or .o, it seems there is a bug, that prevents gnat1 from accepting .obj files. Since normally someone uses gnatmake this was no problem so far? One workaround would be that we set the obj extension to .o for the whole project if ada is enabled in the windows case. This actually means that we have mingw, msys or cygwin and all three use gcc and .o object files should be no problem. I don't know any other ada compiler so that might be an option. Werner |
From: Alan W. I. <ir...@be...> - 2007-03-03 22:06:27
|
On 2007-03-03 21:18+0100 Werner Smekal wrote: > Hi Alan, >> That's a surprising result. What happens for the equivalent PLplot C core >> library build? I assume the extensions for the -o option will be .obj (like >> above), that gcc will build those objects without complaint, and in the next >> step (doing the special linking with gcc to create the shared library) gcc >> will happily link the *.obj files into the shared library. > Yes, gcc has actually no problems with the .obj extension. But gcc seems > to call gnat1 to compile the ada file and though I found a description > of gnat for Windows, where it is explained that the -o option should be > used to set the output filename with the ending .obj or .o, it seems > there is a bug, that prevents gnat1 from accepting .obj files. Since > normally someone uses gnatmake this was no problem so far? I thought gnatmake might be the solution, but I have just done a series of exhaustive tests, and there is no way that it works correctly with the -o option or the -cargs -o options. (In the first case, the -o option is not passed to the compiler. In the latter case it calls the compiler with the correct -o option, but then it checks afterward for the object files it expects in the directory where it was invoked, doesn't find them, and errors out.) I have concluded that gnatmake cannot be used for compiles where you want control of the path+name of the resulting object file. What happens when you run gnatmake testadacompiler.adb where that file consists of the following simple Ada source? procedure testAdaCompiler is begin null; end; On my Debian stable system it simply generates the following commands: irwin@chickadee> gnatmake testadacompiler.adb gcc-3.3 -c testadacompiler.adb gnatbind -x testadacompiler.ali gnatlink testadacompiler.ali Also testadacompiler.o is produced. Does this test produce *.o or *.obj output on MinGW? The point of this test is I am wondering if gnatmake will generate a *.obj file by default, and if it uses special flags on the gcc command to make that happen. From my results above we cannot use gnatmake to compile when we need to control the output path+name, but if this test lets us know the correct compile options for gcc to generate a *.obj, then we can use those flags plus the ordinary gcc -o option to get the desired result on MinGW. 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: Werner S. <sm...@ia...> - 2007-03-04 21:09:49
|
Hi Alan, > What happens when you run gnatmake testadacompiler.adb where that file > consists of the following simple Ada source? > > procedure testAdaCompiler is > begin > null; > end; > For MinGW we obtain: Z:\DevZone>gnatmake testadacompiler.adb gcc -c testadacompiler.adb gnatbind -x testadacompiler.ali gnatlink testadacompiler.ali and we find the following files after the compilation: testadacompiler.adb testadacompiler.ali testadacompiler.exe testadacompiler.o So a .o file is produced not a .obj file (as expected). I search the internet and found this: http://gcc.gnu.org/onlinedocs/gcc-4.0.1/gnat_ugn_unw/Switches-for-gcc.html#Switches-for-gcc If I run gcc on the ada file with the option -v I get: Z:\DevZone>gcc -c testadacompiler.adb -o testadacompiler.obj -v Reading specs from C:/DevZone/MinGW-3.4.5/bin/../lib/gcc/mingw32/3.4.5/specs Configured with: ../gcc-3.4.5/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug Thread model: win32 gcc version 3.4.5 (mingw special) C:/DevZone/MinGW-3.4.5/bin/../libexec/gcc/mingw32/3.4.5/gnat1.exe -quiet -dumpbase testadacompiler.adb -gnatO testadacompiler.obj testadacompiler.adb -o C:\DOKUME~1\smekal\LOKALE~1\Temp/ccmSaaaa.s gnat1: incorrect object file extension > The point of this test is I am wondering if gnatmake will generate a *.obj > file by default, and if it uses special flags on the gcc command to make > that happen. From my results above we cannot use gnatmake to compile when > we need to control the output path+name, but if this test lets us know the > correct compile options for gcc to generate a *.obj, then we can use those > flags plus the ordinary gcc -o option to get the desired result on MinGW. I think gnat1, which is called by gcc, doesn't accept a object file name with any other ending as .o - I tried some other file endings and we have the same problem. So I think this is also a dead end - this is a bug of gnat1 and we need a work around... Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2007-03-04 22:27:57
|
On 2007-03-04 22:09+0100 Werner Smekal wrote: > > I think gnat1, which is called by gcc, doesn't accept a object file name with > any other ending as .o - I tried some other file endings and we have the same > problem. So I think this is also a dead end - this is a bug of gnat1 and we > need a work around... Thanks for your investigation of the Ada/MinGW case. I know your time is quite limited right now, but when you get a chance could you also do a similar investigation for Cygwin? If Cygwin accepts the *.obj form of output files for Ada, then that reinforces your belief the MinGW problem with the .obj extension is a bug, and I would be tempted write-off Ada on MinGW until they correct the bug. OTOH, if Cygwin also cannot accept the *.obj form of output files, then it might be a (stupid) Ada policy to always enforce *.o extensions for compiled objects regardless of platform, and we should find a workaround such as writing a bash script to compile Ada programmes. 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: Jerry <lan...@qw...> - 2007-03-05 11:10:58
|
It sounds like this might be a question for comp.lang.ada if you guys don't get it cracked soon. Jerry On Mar 4, 2007, at 3:27 PM, Alan W. Irwin wrote: > On 2007-03-04 22:09+0100 Werner Smekal wrote: > >> >> I think gnat1, which is called by gcc, doesn't accept a object >> file name with >> any other ending as .o - I tried some other file endings and we >> have the same >> problem. So I think this is also a dead end - this is a bug of >> gnat1 and we >> need a work around... > > Thanks for your investigation of the Ada/MinGW case. > > I know your time is quite limited right now, but when you get a > chance could > you also do a similar investigation for Cygwin? If Cygwin accepts > the *.obj > form of output files for Ada, then that reinforces your belief the > MinGW > problem with the .obj extension is a bug, and I would be tempted > write-off > Ada on MinGW until they correct the bug. OTOH, if Cygwin also > cannot accept > the *.obj form of output files, then it might be a (stupid) Ada > policy to > always enforce *.o extensions for compiled objects regardless of > platform, > and we should find a workaround such as writing a bash script to > compile Ada > programmes. > > Alan > __________________________ |
From: Alan W. I. <ir...@be...> - 2007-03-05 17:16:12
|
On 2007-03-05 04:10-0700 Jerry wrote: > It sounds like this might be a question for comp.lang.ada if you guys > don't get it cracked soon. That's a good idea for the future. However, what we need most now is some comprehensive platform testing. The current form of experimental CMake support for Ada works fine on all Debian and Ubuntu platforms where it has been tested. It does have filename extension problems on MinGW, but at most those problems will affect Cygwin and MinGW, and they might be isolated to just MinGW. To get a comprehensive picture of the overall problems we face with the GNAT version of Ada, we need testing not only on Cygwin, but also additional Linux platforms and Mac OS X. Jerry, I especially urge you to move forward with your Mac OS X testing since that is the platform where you developed the Ada interface, and I want to be sure that our CMake support of that interface is working fine there for you. If after reading http://sourceforge.net/cvs/?group_id=2915 and http://www.miscdebris.net/plplot_wiki/ you still have some questions about or problems with CVS or our CMake build system on Mac OS X, please don't hesitate to post them to this list. 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: Werner S. <sm...@ia...> - 2007-03-05 21:41:04
|
Hi, > However, what we need most now is some comprehensive platform testing. The > current form of experimental CMake support for Ada works fine on all Debian > and Ubuntu platforms where it has been tested. It does have filename > extension problems on MinGW, but at most those problems will affect Cygwin > and MinGW, and they might be isolated to just MinGW. To get a comprehensive > picture of the overall problems we face with the GNAT version of Ada, we > need testing not only on Cygwin, but also additional Linux platforms and Mac > OS X. ok, cygwin test results: * install gcc-ada package with setup.exe of cygwin * export CMAKE_LIBRARY_PATH=/usr/lib/gcc/i686-pc-cygwin/3.4.4/adalib * cmake -DENABLE_ada=ON -DBUILD_TEST=ON -DENABLE_tcl=OFF -DENABLE_tk=OFF -DENABLE_DYNDRIVERS=OFF .. (since tcl/tk driver doesn't work (set to OFF) and dynamic drivers doesn't work (set to OFF)) * make The ada library is build correctly, since the object file ending for cygwin is .o . Examples don't build though: Scanning dependencies of target x01a [ 98%] Building Ada object examples/ada/CMakeFiles/x01a.dir/x01a.o Linking Ada executable x01a.exe gnatmake: "x01a.exe.adb" not found make[2]: *** [examples/ada/x01a.exe] Error 4 make[1]: *** [examples/ada/CMakeFiles/x01a.dir/all] Error 2 make: *** [all] Error 2 So we are kind of really close for cygwin. Werner -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Werner S. <sm...@ia...> - 2007-03-05 22:04:21
|
Hi Alan, I just "found" an easy fix for the object file ending problem. In CMakeAdaCompiler.cmake.in change the last lines to: IF(UNIX OR MINGW) SET(CMAKE_Ada_OUTPUT_EXTENSION .o) ELSE(UNIX OR MINGW) SET(CMAKE_Ada_OUTPUT_EXTENSION .obj) ENDIF(UNIX OR MINGW) So for ada files and MinGW we than have .o files created and the ada bindings library is created nicely. Still the .exe. problem: Scanning dependencies of target x01a [ 96%] Building Ada object examples/ada/CMakeFiles/x01a.dir/x01a.o Linking Ada executable x01a.exe gnatmake: "x01a.exe.adb" not found mingw32-make[2]: *** [examples/ada/x01a.exe] Error 4 mingw32-make[1]: *** [examples/ada/CMakeFiles/x01a.dir/all] Error 2 mingw32-make: *** [all] Error 2 If you think this workaround is ok, I will submit these changes. Regards, Werner Alan W. Irwin wrote: > On 2007-03-05 04:10-0700 Jerry wrote: > >> It sounds like this might be a question for comp.lang.ada if you guys >> don't get it cracked soon. > > That's a good idea for the future. > > However, what we need most now is some comprehensive platform testing. The > current form of experimental CMake support for Ada works fine on all Debian > and Ubuntu platforms where it has been tested. It does have filename > extension problems on MinGW, but at most those problems will affect Cygwin > and MinGW, and they might be isolated to just MinGW. To get a comprehensive > picture of the overall problems we face with the GNAT version of Ada, we > need testing not only on Cygwin, but also additional Linux platforms and Mac > OS X. > > Jerry, I especially urge you to move forward with your Mac OS X testing > since that is the platform where you developed the Ada interface, and I want > to be sure that our CMake support of that interface is working fine there > for you. If after reading http://sourceforge.net/cvs/?group_id=2915 and > http://www.miscdebris.net/plplot_wiki/ you still have some questions about > or problems with CVS or our CMake build system on Mac OS X, please don't > hesitate to post them to this list. > > 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 > __________________________ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Jerry <lan...@qw...> - 2007-03-07 11:19:22
|
I just realized that I fell a day or so behind on reading my list mail. On the weekend I figured out CVS more or less--I made the problem harder by trying to see if the CVS functionality built into Apple's Xcode would help me out and in this case it does not. I'm just following Alan's straightforward instructions for creating and submitting patches. I've downloaded from CVS and got the CVS files connected back to Xcode as best as can be expected. When I tried to compile an example, I got a couple missing symbols which indicated that I needed to upgrade from 5.5.3 that I've been using, so Tuesday I figured out the Cmake stuff and now have my example (not an official plplot example but more complicated) working with 5.7.2. So I believe I'm ready to fix the things that Alan found a few days ago and then generate some more example files. My experience with Cmake on OS X is that it works fine, at least for me. There was one problem that flummoxed me for a bit--the 4.2 compiler that I use from the Mac Ada guys was apparently made without Objective C support which caused Cmake (or make) to complain when trying to access the AquaTerm framework. This is a problem that I believe is a temporary one with this particular 4.2 compiler from macada.org but it's likely to persist for a while. Using an older compiler should cause no problems, but I like the 4.2 version because it has some stuff from the new Ada 200x standard that I like. The workaround while using Cmake was to edit my PATH variable so that Cmake didn't see the 4.2 compiler but the usual compiler. To be clear--this is not a problem with Cmake but only when using Cmake when the current 4.2 compiler from macada.org is installed per their instructions. BTW, anyone who follows the instructions for installing the compiler from macada.org will probably be frustrated because the web site needs updating. The solution is to post to that list and then discover how to download the most recent compiler. I might have discussed this in the Ada readme but I'm not sure right now. Jerry On Mar 5, 2007, at 10:14 AM, Alan W. Irwin wrote: > Jerry, I especially urge you to move forward with your Mac OS X > testing > since that is the platform where you developed the Ada interface, > and I want > to be sure that our CMake support of that interface is working fine > there > for you. If after reading http://sourceforge.net/cvs/?group_id=2915 > and > http://www.miscdebris.net/plplot_wiki/ you still have some > questions about > or problems with CVS or our CMake build system on Mac OS X, please > don't > hesitate to post them to this list. |
From: Alan W. I. <ir...@be...> - 2007-03-05 22:52:08
|
On 2007-03-05 23:03+0100 Werner Smekal wrote: > Hi Alan, > > I just "found" an easy fix for the object file ending problem. In > CMakeAdaCompiler.cmake.in change the last lines to: > > IF(UNIX OR MINGW) > SET(CMAKE_Ada_OUTPUT_EXTENSION .o) > ELSE(UNIX OR MINGW) > SET(CMAKE_Ada_OUTPUT_EXTENSION .obj) > ENDIF(UNIX OR MINGW) > If you think this workaround is ok, I will submit these changes. Good catch, Werner. Please go ahead immediately with that commit. That leaves just the executable suffix issue. I think the thing to do there is to play with SET_TARGET_PROPERTIES (in ada/examples/CMakeLists.txt) until you get something that works. For example, it appears you have control of the output name and/or the SUFFIX. If you can get a build of x01 that way, then to actually get it to execute on MinGW and Cygwin I understand (from informed opinion on the CMake list, :-) ) that you will have to copy x01 to x01.exe. I think the easiest way to do that is with a cmake -e copy command in ada/examples/CMakeLists.txt using the add_custom_command signature that modifies a target result. Anyhow, please play with this executable suffix issue and commit it if you can get something to work on MinGW. I will clean up afterward if necessary. 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: Werner S. <sm...@ia...> - 2007-03-13 10:30:11
|
Hi Alan, Ada bindings and example work now for the MinGW environment. Apart from the fix below I only needed a small change - instead of <TARGET>.adb I used <TARGET_BASE>.adb, since <TARGET_BASE> is the target name without suffix. I also checked that changes in Linux, so these changes should have no impact on Linux and Mac OSX. Just for fun (?) I also ported example 12. Apart from the conclusion that ADA might not become my favorite coding language, I think that plfill() is buggy. This function is imported as "Ada" and not as "C" and though plline() works plfill() doesn't. Changing "Ada" to "C" lead to compilation error for the bindings. Jerry, could you have a look into this? And also if I have ported the example 12 more or less the correct way? Regards, Werner Alan W. Irwin wrote: > On 2007-03-05 23:03+0100 Werner Smekal wrote: > > >> Hi Alan, >> >> I just "found" an easy fix for the object file ending problem. In >> CMakeAdaCompiler.cmake.in change the last lines to: >> >> IF(UNIX OR MINGW) >> SET(CMAKE_Ada_OUTPUT_EXTENSION .o) >> ELSE(UNIX OR MINGW) >> SET(CMAKE_Ada_OUTPUT_EXTENSION .obj) >> ENDIF(UNIX OR MINGW) >> > > >> If you think this workaround is ok, I will submit these changes. >> > > Good catch, Werner. Please go ahead immediately with that commit. > > That leaves just the executable suffix issue. I think the thing to do there > is to play with SET_TARGET_PROPERTIES (in ada/examples/CMakeLists.txt) until > you get something that works. For example, it appears you have control of > the output name and/or the SUFFIX. If you can get a build of x01 that way, > then to actually get it to execute on MinGW and Cygwin I understand (from > informed opinion on the CMake list, :-) ) that you will have to copy x01 to > x01.exe. I think the easiest way to do that is with a cmake -e copy command > in ada/examples/CMakeLists.txt using the add_custom_command signature that > modifies a target result. > > Anyhow, please play with this executable suffix issue and commit it if you > can get something to work on MinGW. I will clean up afterward if necessary. > > 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 > __________________________ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > -- Dipl. Ing. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office) +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Alan W. I. <ir...@be...> - 2007-03-07 17:34:33
|
On 2007-03-07 04:19-0700 Jerry wrote: > [...]so Tuesday > I figured out the Cmake stuff and now have my example (not an > official plplot example but more complicated) working with 5.7.2. So > I believe I'm ready to fix the things that Alan found a few days ago > and then generate some more example files. I am very pleased to hear the CVS version of the Ada interface to PLplot is working for you on Mac OS X, and I look forward to your patches for improving the Ada interface and extending the examples. 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 __________________________ |