From: Alan W. I. <ir...@be...> - 2013-12-02 19:49:56
|
Hi everybody: You have heard from me before about the epa_build project when I was using the preliminary name of "build_projects" for this project. When dreaming up the final "epa_build" name for this project I chose the "epa_" prefix to refer to the method which is to used by the project to control the individual software builds which is CMake's ExternalProject_Add command. Just to remind everyone, the point of epa_build is to make it convenient to build and test PLplot and _all_ its dependencies. Therefore, the epa_build project provides a convenient opportunity for users on Windows platform (where many PLplot dependencies are not readily available unless you build them yourself) to enjoy the full power of PLplot and even more importantly from our perspective test all that power. It also provides an opportunity for Linux, Mac OS X, and Cygwin users to try out PLplot with later versions of dependencies (i.e., Tcl/Tk 8.6) that might not be available as their system version. It turns out that building all of the PLplot dependencies and PLplot itself from source is not going to be a onerous task for modern PC's; my last epa_build (which currently does not include Qt4, but which includes virtually all other PLplot dependencies such as pango/cairo) on Linux with a 5-year-old 2.8GHz 2-CPU box took only 0.5 hours which includes the time required by PLplot to run the test_noninteractive target. I assume that total build and test time will continue to be less than an hour even when the Qt4 build is included. Roughly an hour's worth of computer time is not a bad investment for users to get access to the most powerful version of PLplot on all platforms! The current status of epa_build is I am right in the middle of a transition from using an include(filename) approach for configuring the builds to an add_subdirectory(projectname) approach. The advantage of the latter approach is the CMake variables have a much more limited scope (so that variables set for one project do not affect any other project that is configured). I hope to finish up this transition by later today so that using the new add_subdirectory approach I can replicate what I did before which was to build and test PLplot and all its (non-Qt4) dependencies on Linux. Here is a list of other epa_build agenda items I hope to complete in the next 10 days: * Add a build configuration for Qt4. * Update to the latest Wine and get a "plplot_lite" (PLplot without the pango/cairo, Qt4, and wxwidgets dependencies) build and test to also work on the MinGW/MSYS/Wine platform like it did before the epa_build add_subdirectory reorganization and for an older version of Wine. * Attempt to add a Tcl8.6 and friends build for the Wine case. If that is a success, then our normal Tcl test targets such as test_pltcl_standard_examples and test_tclsh_standard_examples, should work, and there is also a good chance that test_c_ntk will work also since -dev ntk only depends on Tk and not X. Of course, our other Tk test targets (test_c_tk, test_plserver_standard_examples, test_wish_standard_examples, test_plserver_runAllDemos, and test_wish_runAllDemos) will not work on this platform because all the PLplot Tk functionality exercised by those tests ultimately depends on -dev xwin and X. @Arjen: If you are able to finish off the tkwin X to Tk change that I asked for, then test_wish_runAllDemos should also work on MinGW/MSYS and also run much faster on Cygwin (if the speed of -dev ntk on Cygwin is any guide). Also, when I finish off the above agenda items, then epa_build should be directly useful to you for convenient testing of PLplot on the MinGW/MSYS platform. It might also be useful to you on Cygwin if you are interested in testing PLplot for Tcl/Tk8.6 on that platform. (Note that Cygwin currently only provides packages for Tcl/Tk8.5.) Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <Arj...@de...> - 2013-12-03 07:33:25
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > > @Arjen: If you are able to finish off the tkwin X to Tk change that I asked for, then > test_wish_runAllDemos should also work on MinGW/MSYS and also run much faster > on Cygwin (if the speed of -dev ntk on Cygwin is any guide). Also, when I finish off > the above agenda items, then epa_build should be directly useful to you for > convenient testing of PLplot on the MinGW/MSYS platform. It might also be useful to > you on Cygwin if you are interested in testing PLplot for Tcl/Tk8.6 on that platform. > (Note that Cygwin currently only provides packages for > Tcl/Tk8.5.) > That sounds interesting - having a (nearly) complete symmetry among our platforms is definitely worth looking into (some busy days ahead, but I will see what I can do). Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2013-12-06 02:30:33
|
On 2013-12-02 11:49-0800 Alan W. Irwin wrote: > The current status of epa_build is I am right in the middle of a > transition from using an include(filename) approach for configuring > the builds to an add_subdirectory(projectname) approach. The > advantage of the latter approach is the CMake variables have a much > more limited scope (so that variables set for one project do not > affect any other project that is configured). I hope to finish up > this transition by later today so that using the new add_subdirectory > approach I can replicate what I did before which was to build and test > PLplot and all its (non-Qt4) dependencies on Linux. As usual that task took longer than I initially estimated but I have completed it now (revision 12819), and I am extremely pleased with the results of this reorganization and simplification of the epa_build logic. @Arjen: could you try the epa_build project on Cygwin? Obviously any bug fixing you are right in the middle of for PLplot takes precedence so this is only in case you want a break from that activity (or have already done on the easy stuff and want to put off the rest of the Tcl/Tk bug fixing to post-release). Just follow the _Linux_ directions in cmake/epa_build/README. That approach _should_ work in principle since Cygwin advertises itself as "Linux for Windows", but there are likely to be minor glitches for the Cygwin platform for which I would appreciate your feedback. Since this is a new platform entirely, I would start with a really small test by trying to build just one package for the BUILD_THE_BUILDTOOLS=ON case, The last line of the results from cmake shows you what build targets are available. But you can also find the possibilities this way: For BUILD_THE_BUILDTOOLS=ON: wine@raven> make help |grep build_ ... build_all ... rebuild_cache ... build_cmake ... build_pkg-config ... build_swig ... build_libpcre ... build_tk ... build_tcl ... build_itk ... build_iwidgets ... build_itcl3 ... build_itk3 ... build_iwidgets4.0 You might want to pick "build_tcl" as your target since you have an interest in that case. It should only take a few minutes to build and install. If that works, you might want to try build_iwidgets4.0 (which will automatically run most of the rest of the Tcl/Tk epa_build targets through a chain of dependencies setup by the existing epa_build configuration). None of these experiments should take very long. For example, if everything works so you eventually gain enough confidence to try the build_all target, that should take about 10 minutes total. But I should warn the build_cmake target will not work on Cygwin unless you install the required development version of the curl library. (libcurl is a tough build with a lot of dependencies. That is not currently configured in epa_build (see ToDo list below) so currently for all platforms you must either rely on the system version of the development libraries for curl in order to build cmake (easy on Cygwin which has the x86/libcurl-devel/libcurl-devel-7.33.0-1 package available and also easy on Linux) or else you must drop the idea of building cmake with epa_build and instead rely on the system version of CMake or a binary downloadable version of CMake from Kitware for non-Cygwin Windows platforms. Once you have built some/all of the buildtools successfully, then for BUILD_THE_BUILDTOOLS=OFF: (which will have a completely separate build tree and install tree, see the README file) here are the possibilities: ... build_all ... rebuild_cache ... build_ndiff ... build_plplot ... build_plplot-build ... build_plplot-configure ... build_plplot-install ... build_plplot-test ... build_libagg ... build_libharu ... build_libqhull ... build_shapelib ... build_wxwidgets ... build_pango ... build_cairo ... build_fontconfig ... build_gperf ... build_gtk-doc ... build_docbook-xml ... build_libxml2 ... build_docbook-xsl ... build_libxslt ... build_yelp-tools ... build_intltool ... build_itstool ... build_yelp-xsl ... build_pixman ... build_glib ... build_libffi ... build_gobject-introspection ... build_harfbuzz ... build_ragel ... build_plplot_lite ... build_plplot_lite-build ... build_plplot_lite-configure ... build_plplot_lite-install ... build_plplot_lite-test The build_plplot target builds everything on this list other than build_ndiff and build_plplot_lite through a chain of dependencies that is set up by the current epa_build configuration. This series of builds takes a total of 0.5 hours on my Linux platform. The build_plplot_lite target builds a small subset of the above targets in 5 minutes on my platform (by excluding pango and wxwidgets and their dependencies). That is the target I suggest you start with (just to keep everything simple) once you are satisfied with the results of the BUILD_THE_BUILDTOOLS ON case. @Andrew (or any other Unix user here with an interest in building PLplot dependencies as well as PLplot): Please give epa_build a try as well (and also give me feedback concerning any confusing or incomplete instructions in cmake/epa_build/README or any errors you run into). N.B. note I have only talked about the Unix case (Cygwin, Linux, and Mac OS X) so far. I have deliberately excluded non-Cygwin Windows because I _know_ certain of the above build configurations (e.g., tcl and tk) need some changes before they can be expected to work on MinGW/MSYS, for example. In fact, when I got the build_plplot_lite target to work on MinGW/MSYS/Wine some time ago, I relied on binary downloads for some buildtools and ignored others (e.g, Tcl/Tk) and therefore didn't bother with the BUILD_THE_BUILDTOOLS ON case at all. Obviously, build_plplot_lite case by design does not have pango/cairo dependencies. But build_plplot does have those dependencies and I could never get it to work on MinGW/MSYS/Wine (the builds crashed somewhere deep in the pango stack). I don't know whether that was due to a Wine bug (in which case someone with access to MinGW/MSYS on Microsoft Windows should be able to get a lot further) or due to some epa_build configuration issue which was obfuscated so badly by Wine deficiencies that I could not diagnose the problem. Here is the current epa_build ToDo list. * Add a build configuration for Qt4_lite. Unfortunately the Linux from Scratch bible I have used for other build configurations is not suitable here because in this case it goes strictly with the lame autotools approach (with a tonne of fixups they have figured out to get around the limitations of that approach) rather than the preferred (by Qt developers!) CMake approach. So I am going to have to dig a little to figure out the CMake approach for building Qt4. Nevertheless, LFS is still useful in this case because it tells you about the Qt4 dependencies. For epa_build I am going to first emphasize Qt4_lite, the lightest form (fewest dependencies) of Qt4 that is possible that still satisfies PLplot's minimal Qt4 needs. Later on, of course, if somebody was interested they could configure a more complete and powerful form of Qt4 that was suitable, for example, to support even an epa_build configuration for KDE. All of that is a distant dream at this stage, but Qt4_lite is not. * Update to the latest Wine and get a "plplot_lite" (PLplot without the pango/cairo, Qt4, and wxwidgets dependencies) build and test to also work on the MinGW/MSYS/Wine platform like it did before the epa_build add_subdirectory reorganization and for an older version of Wine. * Attempt to add a Tcl8.6 and friends buildtools for the Wine case. If that is a success, then try again with plplot_lite on MinGW/MSYS/Wine. Our normal Tcl test targets such as test_pltcl_standard_examples and test_tclsh_standard_examples, should work, and there is also a good chance that test_c_ntk will work also since -dev ntk only depends on Tk and not X. Of course, our other Tk test targets (test_c_tk, test_plserver_standard_examples, test_wish_standard_examples, test_plserver_runAllDemos, and test_wish_runAllDemos) will not work on this platform because all the PLplot Tk functionality exercised by those tests ultimately depends on -dev xwin and X. * libcurl build configuration following the specific libcurl information (and all its dependencies) in Linux from Scratch <http://www.linuxfromscratch.org/blfs/view/svn/basicnet/curl.html>. A build configuration success with libcurl would free epa_build users of the need to rely on binary versions of CMake which is a worthwhile goal although not nearly as high a priority as Qt4_lite since ABI incompatibility issues are not an issue with binary downloads of CMake (since that is just an application) while they are an issue with binary downloads of the Qt4 set of libraries. Completing the above list should be much easier now that I have reorganized epa_build. However, I am not likely compelete this list before the release. Fortunately, nothing on this list is release critical so will not affect the release timing which is still December 14th (9 days from now). Also, nothing on this list (except possibly dropping the build of CMake and relying on a binary version of CMake instead) is critical for trying out epa_build for yourself. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <Arj...@de...> - 2013-12-06 06:30:47
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > @Arjen: could you try the epa_build project on Cygwin? Obviously any bug fixing > you are right in the middle of for PLplot takes precedence so this is only in case you > want a break from that activity (or have already done on the easy stuff and want to > put off the rest of the Tcl/Tk bug fixing to post-release). > I will give it a go after I have adjusted the F95 bindings for plshades. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <Arj...@de...> - 2013-12-06 07:27:05
|
Hi Alan, Andrew, I fixed the Fortran 95 interface issue for plshades: the rectangular argument is now an optional (last) argument in the call to that routine. With this change I get a perfect match with C example 22. I am not quite sure what the rules are for optional arguments, but the gfortran compiler complained when I had it in a different place, one that mimicked the C API more closely. I will have to investigate that. On the other hand, as the last arguments are reserved for the geometry anyway, it is not that awkward to have it there. Maybe the default value (rectangular is true) should change, but that would be an incompatibility with the previous version. We will need to document this carefully. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <Arj...@de...> - 2013-12-06 07:35:28
|
> > I am not quite sure what the rules are for optional arguments, but the gfortran > compiler complained when I had it in a different place, one that mimicked the C API > more closely. I will have to investigate that. Right, Intel Fortran agrees with gfortran on this, so optional arguments have to appear at the end of the list, which makes sense in a way. If we want it to appear in the same position as the C API, then I will have to use another mechanism. Nothing dramatic, only a bit more code, as I will have to add alternative routines then. Let me know what you think. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2013-12-06 08:07:38
|
On 2013-12-06 07:35-0000 Arjen Markus wrote: >> >> I am not quite sure what the rules are for optional arguments, but the gfortran >> compiler complained when I had it in a different place, one that mimicked the C API >> more closely. I will have to investigate that. > > Right, Intel Fortran agrees with gfortran on this, so optional arguments have to appear at the end of the list, which makes sense in a way. If we want it to appear in the same position as the C API, then I will have to use another mechanism. Nothing dramatic, only a bit more code, as I will have to add alternative routines then. Let me know what you think. Let's use "another mechanism" which I assume is function overloading (which I know is possible with Fortran 95). For me it is quite important to keep the same order of arguments in other languages as in C, and function overloading should gives you the chance to do that. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <Arj...@de...> - 2013-12-06 11:02:55
|
HI Alan, yes, I mean function overloading (via generic interfaces). The C API has two arguments at the end that are not used by the Fortran bindings (as they are pointers to a function and to arbitrary data). The rectangular argument would come in front of whatever the Fortran bindings use instead. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Let's use "another mechanism" which I assume is function overloading (which I know > is possible with Fortran 95). For me it is quite important to keep the same order of > arguments in other languages as in C, and function overloading should gives you the > chance to do that. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation for > stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); > PLplot scientific plotting software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure > Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Andrew R. <and...@us...> - 2013-12-06 13:15:09
|
I agree with Alan. Let's try to keep the interface as similar as possible. This is important for users, and also means we only need to maintain one version of the documentation! Andrew On Fri, Dec 06, 2013 at 11:02:40AM +0000, Arjen Markus wrote: > HI Alan, > > yes, I mean function overloading (via generic interfaces). The C API has two arguments at the > end that are not used by the Fortran bindings (as they are pointers to a function and to arbitrary > data). The rectangular argument would come in front of whatever the Fortran bindings use instead. > > Regards, > > Arjen > > > -----Original Message----- > > From: Alan W. Irwin [mailto:ir...@be...] > > Let's use "another mechanism" which I assume is function overloading (which I know > > is possible with Fortran 95). For me it is quite important to keep the same order of > > arguments in other languages as in C, and function overloading should gives you the > > chance to do that. > > > > Alan > > __________________________ > > Alan W. Irwin > > > > Astronomical research affiliation with Department of Physics and Astronomy, > > University of Victoria (astrowww.phys.uvic.ca). > > > > Programming affiliations with the FreeEOS equation-of-state implementation for > > stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); > > PLplot scientific plotting software package (plplot.sf.net); the libLASi project > > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure > > Project (lbproject.sf.net). > > __________________________ > > > > Linux-powered Science > > __________________________ > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Arjen M. <Arj...@de...> - 2013-12-09 09:35:46
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > > @Arjen: could you try the epa_build project on Cygwin? Obviously any bug fixing > you are right in the middle of for PLplot takes precedence so this is only in case you > want a break from that activity (or have already done on the easy stuff and want to > put off the rest of the Tcl/Tk bug fixing to post-release). > This is failing in the build step for build_ndiff (the first tool to be built): [ 1%] No patch step for 'build_ndiff' [ 1%] No update step for 'build_ndiff' [ 2%] Performing configure step for 'build_ndiff' /usr/bin/env: /usr/bin: No such file or directory ndiff/CMakeFiles/build_ndiff.dir/build.make:112: recipe for target 'epa_build/Stamp/build_ndiff/build_ndiff-configure' failed make[2]: *** [epa_build/Stamp/build_ndiff/build_ndiff-configure] Error 127 CMakeFiles/Makefile2:136: recipe for target 'ndiff/CMakeFiles/build_ndiff.dir/all' failed make[1]: *** [ndiff/CMakeFiles/build_ndiff.dir/all] Error 2 Makefile:75: recipe for target 'all' failed make: *** [all] Error 2 The reason seems to be (see the "/usr/bin" message from /usr/bin/env) that the env command wants a single argument for PATH=..., whereas the makefile has all the directories separately: cd /cygdrive/d/plplot-svn/build-cygwin-epa/epa_build/Build/build_tcl && /usr/bin/env.exe PATH=/usr/local/bin /usr/bin "/cygdrive/c/Program Files (x86)/Intel/Composer XE 2011 SP1/redist/intel64/mkl" ... I have not looked into the way this env command is generated, but it does cause problems on Cygwin. (Also: CMakeLists.txt in tcl and tk uses \unix for the case that MSYS_PLATFORM is turned on - this is seen by CMake as an invalid escape sequence \u. I changed it in my local copy, but my guess is that we can use /unix for all build environments) Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2013-12-09 13:59:21
|
uOn 2013-12-09 09:35-0000 Arjen Markus wrote: > Hi Alan, > > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@be...] >> >> @Arjen: could you try the epa_build project on Cygwin? Obviously any bug fixing >> you are right in the middle of for PLplot takes precedence so this is only in case you >> want a break from that activity (or have already done on the easy stuff and want to >> put off the rest of the Tcl/Tk bug fixing to post-release). >> > > This is failing in the build step for build_ndiff (the first tool to be built): > > [ 1%] No patch step for 'build_ndiff' > [ 1%] No update step for 'build_ndiff' > [ 2%] Performing configure step for 'build_ndiff' > /usr/bin/env: /usr/bin: No such file or directory > ndiff/CMakeFiles/build_ndiff.dir/build.make:112: recipe for target 'epa_build/Stamp/build_ndiff/build_ndiff-configure' failed > make[2]: *** [epa_build/Stamp/build_ndiff/build_ndiff-configure] Error 127 > CMakeFiles/Makefile2:136: recipe for target 'ndiff/CMakeFiles/build_ndiff.dir/all' failed > make[1]: *** [ndiff/CMakeFiles/build_ndiff.dir/all] Error 2 > Makefile:75: recipe for target 'all' failed > make: *** [all] Error 2 > > The reason seems to be (see the "/usr/bin" message from /usr/bin/env) that the env command wants a single argument for PATH=..., whereas the makefile has all the directories separately: > > cd /cygdrive/d/plplot-svn/build-cygwin-epa/epa_build/Build/build_tcl && /usr/bin/env.exe PATH=/usr/local/bin /usr/bin "/cygdrive/c/Program Files (x86)/Intel/Composer XE 2011 SP1/redist/intel64/mkl" ... > > I have not looked into the way this env command is generated, but it does cause problems on Cygwin. > > (Also: CMakeLists.txt in tcl and tk uses \unix for the case that MSYS_PLATFORM is turned on - this is seen by CMake as an invalid escape sequence \u. I changed it in my local copy, but my guess is that we can use /unix for all build environments) Hi Arjen: There are currently known issues with the MSYS_PLATFORM ON case such as the \unix one you reported above so epa_build should not be tried yet for the MinGW/MSYS platform. On the other hand, MSYS_PLATFORM should always be OFF for Cygwin so these known issues should not arise for that platform. I now realize the previous logic could have set MSYS_PLATFORM ON by accident for the Cygwin case. I have fixed that in revision 12829 so MSYS_PLATFORM will always be OFF for Cygwin. That revision should make a very large difference for you unless I have misinterpreted what you have reported. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <Arj...@de...> - 2013-12-09 14:04:03
|
Hi Alan, yes, I just looked at the CMake source code: it might mean the difference between a string and list, which explains why the path was split up into its constituent parts. I will check immediately. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > > Hi Arjen: > > There are currently known issues with the MSYS_PLATFORM ON case such as the > \unix one you reported above so epa_build should not be tried yet for the > MinGW/MSYS platform. On the other hand, MSYS_PLATFORM should always be > OFF for Cygwin so these known issues should not arise for that platform. > > I now realize the previous logic could have set MSYS_PLATFORM ON by accident > for the Cygwin case. I have fixed that in revision 12829 so MSYS_PLATFORM will > always be OFF for Cygwin. > > That revision should make a very large difference for you unless I have > misinterpreted what you have reported. > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <Arj...@de...> - 2013-12-09 14:09:49
|
Hi Alan, > -----Original Message----- > From: Arjen Markus [mailto:Arj...@de...] > Sent: Monday, December 09, 2013 3:04 PM > To: PLplot development list > Subject: Re: [Plplot-devel] The epa_build project > > Hi Alan, > > yes, I just looked at the CMake source code: it might mean the difference between a > string and list, which explains why the path was split up into its constituent parts. > I will check immediately. > make is happier with this change, but there is still something wrong: checking for library containing deflateSetHeader... -lz checking for ranlib... ranlib checking if 64bit support is requested... yes checking if 64bit Sparc VIS support is requested... no checking if compiler supports visibility "hidden"... yes checking if rpath support is requested... yes checking system version... CYGWIN_NT-6.1-1.7.27(0.271/5/3) checking for dlopen in -ldl... yes checking for ar... ar checking for Cygwin version of gcc... yes configure: error: Please configure and make the ../win directory first. tcl/CMakeFiles/build_tcl.dir/build.make:110: recipe for target 'epa_build/Stamp/build_tcl/build_tcl-configure' failed make[3]: *** [epa_build/Stamp/build_tcl/build_tcl-configure] Error 1 CMakeFiles/Makefile2:373: recipe for target 'tcl/CMakeFiles/build_tcl.dir/all' failed make[2]: *** [tcl/CMakeFiles/build_tcl.dir/all] Error 2 CMakeFiles/Makefile2:385: recipe for target 'tcl/CMakeFiles/build_tcl.dir/rule' failed make[1]: *** [tcl/CMakeFiles/build_tcl.dir/rule] Error 2 Makefile:187: recipe for target 'build_tcl' failed make: *** [build_tcl] Error 2 This may be due to an ambiguity - Cygwin being somewhere between Linux and Windows. I have no idea how to build Tcl on Cygwin though - I have sofar used the prebuilt version. My first guess would be that it is built as under UNIX/Linux, given all the available tools. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2013-12-09 15:36:26
|
On 2013-12-09 14:09-0000 Arjen Markus wrote: > make is happier with this [MSYS_PLATFORM OFF for cygwin] change, but there is still something wrong: > > checking for library containing deflateSetHeader... -lz > checking for ranlib... ranlib > checking if 64bit support is requested... yes > checking if 64bit Sparc VIS support is requested... no > checking if compiler supports visibility "hidden"... yes > checking if rpath support is requested... yes > checking system version... CYGWIN_NT-6.1-1.7.27(0.271/5/3) > checking for dlopen in -ldl... yes > checking for ar... ar > checking for Cygwin version of gcc... yes > configure: error: Please configure and make the ../win directory first. > tcl/CMakeFiles/build_tcl.dir/build.make:110: recipe for target 'epa_build/Stamp/build_tcl/build_tcl-configure' failed > make[3]: *** [epa_build/Stamp/build_tcl/build_tcl-configure] Error 1 > CMakeFiles/Makefile2:373: recipe for target 'tcl/CMakeFiles/build_tcl.dir/all' failed > make[2]: *** [tcl/CMakeFiles/build_tcl.dir/all] Error 2 > CMakeFiles/Makefile2:385: recipe for target 'tcl/CMakeFiles/build_tcl.dir/rule' failed > make[1]: *** [tcl/CMakeFiles/build_tcl.dir/rule] Error 2 > Makefile:187: recipe for target 'build_tcl' failed > make: *** [build_tcl] Error 2 > > This may be due to an ambiguity - Cygwin being somewhere between Linux and Windows. > I have no idea how to build Tcl on Cygwin though - I have sofar used the prebuilt version. My first guess > would be that it is built as under UNIX/Linux, given all the available tools. That was my guess as well, but it appears from the results above that the autotools-based build system for Tcl independently detects the Cygwin platform and demands you use the win subdirectory in that case. Therefore here is my guess for what might work: Current logic in tcl/CMakeLists.txt if(MSYS_PLATFORM) set(source_PATH ${source_PATH}\unix) else(MSYS_PLATFORM) set(source_PATH ${source_PATH}/unix) endif(MSYS_PLATFORM) ==> if(MSYS_PLATFORM) set(source_PATH ${source_PATH}\\win) elseif(CYGWIN) set(source_PATH ${source_PATH}/win) else set(source_PATH ${source_PATH}/unix) endif(MSYS_PLATFORM) That first change to \\win is irrelevant to you since MSYS_PLATFORM is OFF, but nevertheless that is my guess for what might work in the MinGW/MSYS case. Of course, for both the MinGW/MSYS and Cygwin platforms we are both guessing here because we are both unfamiliar with the autotools build for Tcl on either of those platforms, but the above change is worth a try. If the above guess doesn't work on Cygwin, then I suggest you put this aside for the time being and test other components of the -DBUILD_THE_BUILDTOOLS=ON case to see what works and what doesn't on Cygwin. Then move on to the (default) -DBUILD_THE_BUILDTOOLS=OFF case for epa_build which assuming you have set up your setup/setup_cygwin file correctly (see setup/setup_linux for a template of how to set up that file) will use the -DBUILD_THE_BUILDTOOLS=ON results when they are available but otherwise use the system versions (e.g. for Tcl and Tk). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <Arj...@de...> - 2013-12-09 19:39:46
|
Hi Alan, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > > That was my guess as well, but it appears from the results above that the autotools- > based build system for Tcl independently detects the Cygwin platform and demands > you use the win subdirectory in that case. > > Therefore here is my guess for what might work: > > Current logic in tcl/CMakeLists.txt > > if(MSYS_PLATFORM) > set(source_PATH ${source_PATH}\unix) > else(MSYS_PLATFORM) > set(source_PATH ${source_PATH}/unix) > endif(MSYS_PLATFORM) > > ==> > > if(MSYS_PLATFORM) > set(source_PATH ${source_PATH}\\win) > elseif(CYGWIN) > set(source_PATH ${source_PATH}/win) > else > set(source_PATH ${source_PATH}/unix) > endif(MSYS_PLATFORM) > > That first change to \\win is irrelevant to you since MSYS_PLATFORM is OFF, but > nevertheless that is my guess for what might work in the MinGW/MSYS case. > > Of course, for both the MinGW/MSYS and Cygwin platforms we are both guessing > here because we are both unfamiliar with the autotools build for Tcl on either of those > platforms, but the above change is worth a try. > I have tried building Tcl manually by first configuring and making the win directory as suggested in the error message, but I ended up having to change the generated Makefile, as the ./configure script insisted on setting the C compiler to "x86_64-w64-mingw32-gcc" and similarly for other tools. Then I ran into a compile error with a type TCHAR. I remember having similar trouble before. This is something peculiar to Cygwin, I am afraid. I will leave this for the moment and see what other things pop up with other targets. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <Arj...@de...> - 2013-12-09 20:05:24
|
Hi Alan, > -----Original Message----- > From: Arjen Markus [mailto:Arj...@de...] > > Then I ran into a compile error with a type TCHAR. I remember having similar trouble > before. This is something peculiar to Cygwin, I am afraid. I will leave this for the > moment and see what other things pop up with other targets. > I tried the following targets: - build_swig: this worked fine (implied build_libprce, so that is fine too) - build_pkg-config: problem in gutils.c because glib_dll is not declared. Probable cause: we need to define a macro G_OS_WIN32, as the identifier is conditionally defined in glib-init.h - build_cmake: an undefined reference to "cygwin_conv_to_win32_path" during the link step As the others are Tcl/Tk-related or have some special purpose (edit_cache for instance), I did not try them. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2013-12-09 21:03:39
|
On 2013-12-09 20:05-0000 Arjen Markus wrote: > Hi Alan, > >> -----Original Message----- >> From: Arjen Markus [mailto:Arj...@de...] >> >> Then I ran into a compile error with a type TCHAR. I remember having similar trouble >> before. This is something peculiar to Cygwin, I am afraid. I will leave this for the >> moment and see what other things pop up with other targets. >> > > I tried the following targets: > > - build_swig: this worked fine (implied build_libprce, so that is fine too) I am very pleased to hear that since it shows the basic CMake logic and dependency checking in epa_build is being done correctly on the Cygwin platform. > - build_pkg-config: problem in gutils.c because glib_dll is not declared. Probable cause: we need to define a macro G_OS_WIN32, > as the identifier is conditionally defined in glib-init.h. You can add a platform-specific macro in epa_build as follows: In pkg-config/CMakeLists.txt you will see a series of platform-specific logic blocks: if(MSYS_PLATFORM) # configure (for glib subpackage) dies without this. set(CFLAGS "-march=native $ENV{CFLAGS}") # These changes cause improved test results (three failures rather than 4) # on Wine, see <https://bugs.freedesktop.org/show_bug.cgi?id=66939> set(BUILD_IN_SOURCE 1) set(BUILD_COMMAND ${EPA_MAKE_COMMAND}) else(MSYS_PLATFORM) set(CFLAGS "$ENV{CFLAGS}") # No changes from defaults required to get perfect test results # on Linux. set(BUILD_IN_SOURCE 0) set(BUILD_COMMAND ${EPA_PARALLEL_MAKE_COMMAND}) endif(MSYS_PLATFORM) So just add another platform stanza before the else with everything except CFLAGS done as for Linux (to start at least): elseif(CYGWIN) set(CFLAGS "G_OS_WIN32 -D$ENV{CFLAGS}") # No changes from defaults required to get perfect test results # on Cygwin? set(BUILD_IN_SOURCE 0) set(BUILD_COMMAND ${EPA_PARALLEL_MAKE_COMMAND}) I hope that works because pkg-config is pretty important for PLplot. > - build_cmake: an undefined reference to "cygwin_conv_to_win32_path" during the link step. That's strange. I thought cmake just built out of the box on Cygwin. This should be followed up but as a low priority since it isn't a showstopper. > As the others are Tcl/Tk-related or have some special purpose (edit_cache for instance), I did not try them. Do you know enough about Cygwin so you can dissect how the packages are built? That (or a post to one of the Cygwin experts you know) might be able to help you figure out how to build tcl by hand, and then once you have had success with that, it should be trivial to do the same thing with epa_build using a small modification of tcl/CMakeLists.txt. However, figuring that out will take time so for now here is what I suggest you do. 1) Get the above fixup to work for pkg-config 2) Try the default -DBUILD_THE_BUILDTOOLS=OFF case. For that case if you have edited and used setup/setup_cygwin properly, you will end up using your successful buildtool results for swig and pkg-config. However, for every other buildtool (cmake and all the tcl/tk stuff) where you are currently stopped from building the tool yourself, you will end up using the system versions of those instead which is a good temporary workaround which allows you to move ahead with testing the -DBUILD_THE_BUILDTOOLS=OFF builds. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2013-12-10 01:09:50
|
On 2013-12-09 13:03-0800 Alan W. Irwin wrote: > Do you know enough about Cygwin so you can dissect how the packages are > built? In case you aren't experenced yet with dissecting Cygwin packages, I have just figured out how to do that. It turns out they are a treasure trove of build information for Cygwin and may also give some relevant build information and patches for the MinGW/MSYS case. Let's say you are having trouble with pkg-config. Then for any Cygwin mirror look at http://mirror.mcs.anl.gov/cygwin/x86_64/release/pkg-config (I used the x86_64 version because that seemed to be much more modern than x86 in the pkg-config case.) >From that mirror (or any other) download the package source tarball, pkg-config-0.27.1-1-src.tar.bz2 and unpack it. In there, you will find a patch, glib-cygwin.patch, which I discovered applies cleanly to the latest version of pkg-config used by epa_build/pkg_config and is all about changes having to do with G_OS_WIN32. So I am virtually positive that applying that patch will completely fix the G_OS_WIN32 issue you discovered and may also help out the MinGW/MSYS case where pkg_config builds OK, but fails a small percentage of the tests. I also had a look at the pkg-config.cygport file in that unpacked tarball, but I don't think there is anything relevant because all the logic seemed to be concerned with cross-compiling. I want to do some testing of glib-cygwin.patch on all platforms accessible to me so please standby until I make a relevant commit to epa_build/pkg_config (probably Tuesday). I am now going to go through the same Cygwin package dissection process for tcl, and I will post later about what I find out in that case. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Alan W. I. <ir...@be...> - 2013-12-10 02:36:45
|
On 2013-12-09 17:09-0800 Alan W. Irwin wrote: > I am now going to go through the same Cygwin package dissection > process for tcl, and I will post later about what I find out in that > case. The Cygwin package tarball for tcl is named tcl-8.5.11-1-src.tar.bz2 which you can find in any Cygwin mirror. The tcl.cygport file in there shows that the 8.5-cygwin.patch and 8.5.10-tea-m4.patch patches are applied, and also shows the Tcl source subdirectory that is used is unix and not win! I don't see anything else in that tcl.cygport file that is relevant (at least at the present time when I am still fairly ignorant of Cygwin packaging procedures). I am pretty sure that the 8.5.10-tea-m4.patch (which appears to be only for Cygwin packaging backwards compatibility) is not relevant to the epa_build case so for a start (probably on Wednesday, see my ToDo list below) I will try the 8.5-cygwin.patch to see if that helps out the MinGW/MSYS case using the win subdirectory of the tcl source code. (This will be my first attempt at building tcl on MinGW/MSYS.) Meanwhile, will you please try applying the 8.5-cygwin.patch yourself and building tcl (using the unix subdirectory) by hand on Cygwin? That patch appears to be relevant to the errors you encountered when you last attempted to build using the unix subdirectory so I have some degree of optimism you will have complete success with that build. We should be able to update epa_build/tcl/CMakeLists.txt to codify whatever we discover is required to get build success on Cygwin and/or MinGW/MSYS. To put this all in context, here is what I plan to do in the next two days in the order given here. (1) I have finished implementing a completely clean epa_build of qt4_lite today (which only takes 15 minutes by the way) on Linux. This is an extrmely welcome result since it fills in the last hole (except for octave) in the epa_build configurations for the PLplot dependencies and enables one of our best device drivers. When testing that build I got through most PLplot qt-related tests, but I also discovered some release-critical issues with the PLplot (not epa_build) build-system for the qt components of PLplot. So dealing with those is my number-one priority. (2) Deal with the epa_build issues for pkg-config I described in my previous post which will require MinGW/MSYS testing which unfortunately is painfully slow on Wine. (3) Deal with the epa_build issues for tcl mentioned here for the MinGW/MSYS case which will also be painfully slow on Wine. I hope to finish (1) and (2) by Tuesday, and (3) by Wednesday, but we will see how it goes. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <Arj...@de...> - 2013-12-10 08:02:15
|
Hi Alan, hm, > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > > ... > You can add a platform-specific macro in epa_build as follows: > ... I need at least: elseif(CYGWIN) set(CFLAGS "-DG_OS_WIN32 -D_MSC_VER $ENV{CFLAGS}") # No changes from defaults required to get perfect test results # on Cygwin? set(BUILD_IN_SOURCE 0) set(BUILD_COMMAND ${EPA_PARALLEL_MAKE_COMMAND}) but even then I get a large bunch of error messages. I will send you the entire output from make, but here is an excerpt: /cygdrive/d/plplot-svn/build-cygwin-epa/epa_build/Source/build_pkg-config/glib/glib/gdir.c:60:3: error: unknown type name '_WDIR' _WDIR *wdirp; ... /cygdrive/d/plplot-svn/build-cygwin-epa/epa_build/Source/build_pkg-config/glib/glib/win_iconv.c:792:18: error: '_errno' undeclared (first use in this function) cd->_errno = _errno; ... /cygdrive/d/plplot-svn/build-cygwin-epa/epa_build/Source/build_pkg-config/glib/glib/gdir.c:224:30: error: dereferencing pointer to incomplete type && (0 == wcscmp (wentry->d_name, L".") || ... /cygdrive/d/plplot-svn/build-cygwin-epa/epa_build/Source/build_pkg-config/glib/glib/gconvert.c: At top level: /cygdrive/d/plplot-svn/build-cygwin-epa/epa_build/Source/build_pkg-config/glib/glib/gconvert.c:62:2: error: #error GNU libiconv in use but included iconv.h not from libiconv #error GNU libiconv in use but included iconv.h not from libiconv It would seem we need yet another patch ... Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Arjen M. <Arj...@de...> - 2013-12-10 08:07:05
|
Hi Alan, I will contact the Tcl+Cygwin expert about this. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Tuesday, December 10, 2013 3:37 AM > To: Arjen Markus > Cc: PLplot development list > Subject: Re: [Plplot-devel] The epa_build project > > On 2013-12-09 17:09-0800 Alan W. Irwin wrote: > > > I am now going to go through the same Cygwin package dissection > > process for tcl, and I will post later about what I find out in that > > case. > > The Cygwin package tarball for tcl is named tcl-8.5.11-1-src.tar.bz2 which you can > find in any Cygwin mirror. The tcl.cygport file in there shows that the 8.5- > cygwin.patch and 8.5.10-tea-m4.patch patches are applied, and also shows the Tcl > source subdirectory that is used is unix and not win! I don't see anything else in that > tcl.cygport file that is relevant (at least at the present time when I am still fairly > ignorant of Cygwin packaging procedures). > > I am pretty sure that the 8.5.10-tea-m4.patch (which appears to be only for Cygwin > packaging backwards compatibility) is not relevant to the epa_build case so for a > start (probably on Wednesday, see my ToDo list below) I will try the 8.5-cygwin.patch > to see if that helps out the MinGW/MSYS case using the win subdirectory of the tcl > source code. > (This will be my first attempt at building tcl on MinGW/MSYS.) > > Meanwhile, will you please try applying the 8.5-cygwin.patch yourself and building tcl > (using the unix subdirectory) by hand on Cygwin? That patch appears to be relevant > to the errors you encountered when you last attempted to build using the unix > subdirectory so I have some degree of optimism you will have complete success with > that build. > > We should be able to update epa_build/tcl/CMakeLists.txt to codify whatever we > discover is required to get build success on Cygwin and/or MinGW/MSYS. > > To put this all in context, here is what I plan to do in the next two days in the order > given here. > > (1) I have finished implementing a completely clean epa_build of qt4_lite today > (which only takes 15 minutes by the way) on Linux. This is an extrmely welcome > result since it fills in the last hole (except for octave) in the epa_build configurations > for the PLplot dependencies and enables one of our best device drivers. When > testing that build I got through most PLplot qt-related tests, but I also discovered > some release-critical issues with the PLplot (not > epa_build) build-system for the qt components of PLplot. So dealing with those is my > number-one priority. > > (2) Deal with the epa_build issues for pkg-config I described in my previous post > which will require MinGW/MSYS testing which unfortunately is painfully slow on Wine. > > (3) Deal with the epa_build issues for tcl mentioned here for the MinGW/MSYS case > which will also be painfully slow on Wine. > > I hope to finish (1) and (2) by Tuesday, and (3) by Wednesday, but we will see how it > goes. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation for > stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); > PLplot scientific plotting software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure > Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2013-12-10 09:20:39
|
On 2013-12-10 08:02-0000 Arjen Markus wrote: > Hi Alan, > > hm, > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@be...] >> >> ... >> You can add a platform-specific macro in epa_build as follows: >> ... > > I need at least: > > elseif(CYGWIN) > set(CFLAGS "-DG_OS_WIN32 -D_MSC_VER $ENV{CFLAGS}") > # No changes from defaults required to get perfect test results > # on Cygwin? > set(BUILD_IN_SOURCE 0) > set(BUILD_COMMAND ${EPA_PARALLEL_MAKE_COMMAND}) > > but even then I get a large bunch of error messages. As expected. In a later e-mail about dissection of the pkg-config case I found a patch that does a lot more concerning G_OS_WIN32 fixups. You have a choice of waiting for me to make that patch part of epa_build (number 2 on my agenda) or following how I dissected the Cygwin package for pkg-config (which I described so I am sure you could follow it) and trying that patch yourself. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <Arj...@de...> - 2013-12-10 09:24:10
|
Hi Alan, I may look into this later today - right now I am busy with my day job ;). Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Tuesday, December 10, 2013 10:21 AM > To: Arjen Markus > Cc: PLplot development list > Subject: RE: [Plplot-devel] The epa_build project > > On 2013-12-10 08:02-0000 Arjen Markus wrote: > > > Hi Alan, > > > > hm, > > > >> -----Original Message----- > >> From: Alan W. Irwin [mailto:ir...@be...] > >> > >> ... > >> You can add a platform-specific macro in epa_build as follows: > >> ... > > > > I need at least: > > > > elseif(CYGWIN) > > set(CFLAGS "-DG_OS_WIN32 -D_MSC_VER $ENV{CFLAGS}") > > # No changes from defaults required to get perfect test results > > # on Cygwin? > > set(BUILD_IN_SOURCE 0) > > set(BUILD_COMMAND ${EPA_PARALLEL_MAKE_COMMAND}) > > > > but even then I get a large bunch of error messages. > > As expected. In a later e-mail about dissection of the pkg-config case I found a patch > that does a lot more concerning G_OS_WIN32 fixups. > > You have a choice of waiting for me to make that patch part of epa_build (number 2 > on my agenda) or following how I dissected the Cygwin package for pkg-config > (which I described so I am sure you could follow it) and trying that patch yourself. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state implementation for > stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); > PLplot scientific plotting software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure > Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2013-12-10 09:26:18
|
On 2013-12-10 08:06-0000 Arjen Markus wrote: > Hi Alan, > > I will contact the Tcl+Cygwin expert about this. While waiting for his reply I suggest you simply try the experiment of applying the patch you can obtain from the tcl Cygwin package tarball like I explain below. That is bound to be part of his reply, and it may be his complete reply. Alan > > Regards, > > Arjen > >> -----Original Message----- >> From: Alan W. Irwin [mailto:ir...@be...] >> Sent: Tuesday, December 10, 2013 3:37 AM >> To: Arjen Markus >> Cc: PLplot development list >> Subject: Re: [Plplot-devel] The epa_build project >> >> On 2013-12-09 17:09-0800 Alan W. Irwin wrote: >> >>> I am now going to go through the same Cygwin package dissection >>> process for tcl, and I will post later about what I find out in that >>> case. >> >> The Cygwin package tarball for tcl is named tcl-8.5.11-1-src.tar.bz2 which you can >> find in any Cygwin mirror. The tcl.cygport file in there shows that the 8.5- >> cygwin.patch and 8.5.10-tea-m4.patch patches are applied, and also shows the Tcl >> source subdirectory that is used is unix and not win! I don't see anything else in that >> tcl.cygport file that is relevant (at least at the present time when I am still fairly >> ignorant of Cygwin packaging procedures). >> >> I am pretty sure that the 8.5.10-tea-m4.patch (which appears to be only for Cygwin >> packaging backwards compatibility) is not relevant to the epa_build case so for a >> start (probably on Wednesday, see my ToDo list below) I will try the 8.5-cygwin.patch >> to see if that helps out the MinGW/MSYS case using the win subdirectory of the tcl >> source code. >> (This will be my first attempt at building tcl on MinGW/MSYS.) >> >> Meanwhile, will you please try applying the 8.5-cygwin.patch yourself and building tcl >> (using the unix subdirectory) by hand on Cygwin? That patch appears to be relevant >> to the errors you encountered when you last attempted to build using the unix >> subdirectory so I have some degree of optimism you will have complete success with >> that build. >> >> We should be able to update epa_build/tcl/CMakeLists.txt to codify whatever we >> discover is required to get build success on Cygwin and/or MinGW/MSYS. >> >> To put this all in context, here is what I plan to do in the next two days in the order >> given here. >> >> (1) I have finished implementing a completely clean epa_build of qt4_lite today >> (which only takes 15 minutes by the way) on Linux. This is an extrmely welcome >> result since it fills in the last hole (except for octave) in the epa_build configurations >> for the PLplot dependencies and enables one of our best device drivers. When >> testing that build I got through most PLplot qt-related tests, but I also discovered >> some release-critical issues with the PLplot (not >> epa_build) build-system for the qt components of PLplot. So dealing with those is my >> number-one priority. >> >> (2) Deal with the epa_build issues for pkg-config I described in my previous post >> which will require MinGW/MSYS testing which unfortunately is painfully slow on Wine. >> >> (3) Deal with the epa_build issues for tcl mentioned here for the MinGW/MSYS case >> which will also be painfully slow on Wine. >> >> I hope to finish (1) and (2) by Tuesday, and (3) by Wednesday, but we will see how it >> goes. >> >> Alan >> __________________________ >> Alan W. Irwin >> >> Astronomical research affiliation with Department of Physics and Astronomy, >> University of Victoria (astrowww.phys.uvic.ca). >> >> Programming affiliations with the FreeEOS equation-of-state implementation for >> stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); >> PLplot scientific plotting software package (plplot.sf.net); the libLASi project >> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure >> Project (lbproject.sf.net). >> __________________________ >> >> Linux-powered Science >> __________________________ > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. > __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <Arj...@de...> - 2013-12-10 09:28:12
|
Hi Alan, true, but that is also something for later today. Regards, Arjen > -----Original Message----- > From: Alan W. Irwin [mailto:ir...@be...] > Sent: Tuesday, December 10, 2013 10:26 AM > To: Arjen Markus > Cc: PLplot development list > Subject: Re: [Plplot-devel] The epa_build project > > On 2013-12-10 08:06-0000 Arjen Markus wrote: > > > Hi Alan, > > > > I will contact the Tcl+Cygwin expert about this. > > While waiting for his reply I suggest you simply try the experiment of applying the > patch you can obtain from the tcl Cygwin package tarball like I explain below. That is > bound to be part of his reply, and it may be his complete reply. > > Alan > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |