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 > Plplot-devel@lists.sourceforge.net > 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: [EMAIL PROTECTED] 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 ------------------------------------------------------------------------- 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 Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel