From: Alan W. I. <ir...@be...> - 2006-03-19 06:40:12
|
I was reading an LJ story (http://www.linuxjournal.com/article/8928) today on musical notation software, and I noticed two of the three reviewed tools were built with the SCons (http://www.scons.org/) build-management system. It appears it is a python-based replacement for make (!), automake, and autoconf. It is licensed under the MIT license. There was no mention of a libtool replacement, but obviously the project is building up expertise on various platforms (including windows) that may eventually give it that sort of cross-platform build capability. It is nice to know that autotools is finally beginning to receive some competition in the free software space. I doubt very much that we will want to move the Unix part of PLplot (including Cygwin and MinGW) from autotools to SCons any time soon, if ever. However, Arjen, since you cannot use autotools for your (bare) windows builds, you might want to have a look at SCons to see whether it can help you with your PLplot configuration issues you have previously mentioned on that platform. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 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...> - 2006-03-19 09:23:12
|
Hi all, I already use scons for some of my (cross platform) projects, and also for wxplplot - some sort of plplot-"distribution" for the wxwidgets driver for windows (and linux/mac osx), which I didn't provide for the community since I'm not really there, where it should be (actually I did provide it (http://eaps4.iap.tuwien.ac.at/~smekal/wxplplot/), but nobody knows, since I didn't announce it - Linux and Mac OSX don't work out of the box). Anyway, I can provide my scons file (which for example checks if the gd and/or the freetype library is there) if someone is interested. Apart from that, scons is very useful, and you can already use it as make-replacement without problems (e.g. it's used for the Linux build of Doom 3). It can e.g. also provide project files for Microsoft Visual C++, but in the moment only for 6.0 and it has some rough edges here and there. But it is still a pre-release and I hope the provide a newer version soon, since in cvs are already some nive enhancements included. So, if someone is interested in the Sconscript file, you can download from the wxPLplot homepage, and I can also help with setting up. Regards, Werner Alan W. Irwin wrote: > I was reading an LJ story (http://www.linuxjournal.com/article/8928) today > on musical notation software, and I noticed two of the three reviewed tools > were built with the SCons (http://www.scons.org/) build-management system. > > It appears it is a python-based replacement for make (!), automake, and > autoconf. It is licensed under the MIT license. There was no mention of a > libtool replacement, but obviously the project is building up expertise on > various platforms (including windows) that may eventually give it that sort > of cross-platform build capability. > > It is nice to know that autotools is finally beginning to receive some > competition in the free software space. I doubt very much that we will > want > to move the Unix part of PLplot (including Cygwin and MinGW) from autotools > to SCons any time soon, if ever. However, Arjen, since you cannot use > autotools for your (bare) windows builds, you might want to have a look at > SCons to see whether it can help you with your PLplot configuration issues > you have previously mentioned on that platform. > > Alan > __________________________ > Alan W. Irwin > email: ir...@be... > phone: 250-727-2902 > > 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 > __________________________ > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Arjen M. <arj...@wl...> - 2006-04-12 07:03:44
|
Alan W. Irwin wrote: > I was reading an LJ story (http://www.linuxjournal.com/article/8928) > today > on musical notation software, and I noticed two of the three reviewed > tools > were built with the SCons (http://www.scons.org/) build-management > system. > > It appears it is a python-based replacement for make (!), automake, and > autoconf. It is licensed under the MIT license. There was no mention > of a > libtool replacement, but obviously the project is building up > expertise on > various platforms (including windows) that may eventually give it that > sort > of cross-platform build capability. > > It is nice to know that autotools is finally beginning to receive some > competition in the free software space. I doubt very much that we > will want > to move the Unix part of PLplot (including Cygwin and MinGW) from > autotools > to SCons any time soon, if ever. However, Arjen, since you cannot use > autotools for your (bare) windows builds, you might want to have a > look at > SCons to see whether it can help you with your PLplot configuration > issues > you have previously mentioned on that platform. I am - in principle - interested in SCons - I have encountered it before. However, there is one fundamental or perhaps better cultural issue: people who build software on Windows do not routinely go and hunt for auxiliary packages, they expect everything to be there. Well, I exaggerate a bit. The solution I have in mind that will give me the necessary flexibility is a small footprint implementation of the Tcl language, called Jim. This will allow me to set up a simple configuration tool in a language I know well. The source code for Jim is no more than 0.5 MB and what is more, it is very easy to compile. I have started developing the tool I have in mind and it boils down to the user starting a batch file and then the Jim interpreter is built if it does not exist and the configuration tool is then started. Almost as if you would be using ./configure ... Main problem besides time: decide what options the user should have ... and where to find the auxiliary libraries (if they are already installed). The experience with the UNICODE stuff has been enlightening though. Regards, Arjen |
From: Robert S. <ro...@sc...> - 2006-04-16 17:13:03
|
On Wed, Apr 12, 2006 at 08:59:50AM +0200, Arjen Markus wrote: > I have started developing the tool I have in mind and it boils down to > the user starting a batch file and then the Jim interpreter is built > if it does not exist and the configuration tool is then started. > Almost as if you would be using ./configure ... Forget about that. I'm pretty sure that all non-mainstream build tools forget about >90% of the problems which occur during the usual scenarios which are serviced by the autotools. Think of cross compiling with host-side tests, pkg-configisation or sysroot/destdir support. Cross platform compiling is _difficult_ and can only be solved by a community with reasonable critical mass. It's pretty good that scons is a competitor for autotools and it seems to gain critical mass, but nearly all other systems out there are just a useless hack which solves somebody's problem. So don't waste your time. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 |
From: Alan W. I. <ir...@be...> - 2006-04-16 18:39:28
|
On 2006-04-16 19:12+0200 Robert Schwebel wrote: > On Wed, Apr 12, 2006 at 08:59:50AM +0200, Arjen Markus wrote: >> I have started developing the tool I have in mind and it boils down to >> the user starting a batch file and then the Jim interpreter is built >> if it does not exist and the configuration tool is then started. >> Almost as if you would be using ./configure ... > > Forget about that. I'm pretty sure that all non-mainstream build tools > forget about >90% of the problems which occur during the usual scenarios > which are serviced by the autotools. Think of cross compiling with > host-side tests, pkg-configisation or sysroot/destdir support. Cross > platform compiling is _difficult_ and can only be solved by a community > with reasonable critical mass. It's pretty good that scons is a > competitor for autotools and it seems to gain critical mass, but nearly > all other systems out there are just a useless hack which solves > somebody's problem. So don't waste your time. > Just to clarify the issues, most of our PLplot platforms (including MinGW/MSYS, Cygwin, and Mac OS X) are configured with autotools (for the reasons Robert describes). As far as I know we have not yet gotten autotools to work on djgpp, but I still have some hope there. Thus, autotools is our fundamental cross-platform configuration method. But we don't feel there is any hope for the autotools approach to work for a bare windows platform which is why Arjen is working on an alternative method for just that case alone. Thus, there are no cross-platform PLplot issues with Arjen's approach by definition since it will only be used for one platform. One possibility to simplify Arjen's life is to drop support for the bare windows platform and ask our windows users to use the MinGW/MSYS approach instead. That method does seem to have extraordinary appeal for windows users and developers; there were something like 1.5 million (!) downloads for MinGW from sourceforge in the last 12 months, and in that time they usually have been in the top 20 most active SF projects (see http://sourceforge.net/project/stats/?group_id=2435&ugn=mingw&type=&mode=year). Also, the PLplot MinGW/MSYS platform is coming along well; for example, in the last year we finally figured out how to get shared libraries to work on it. The only limitation I am aware of for the PLplot MinGW/MSYS platform is dynamic devices (plug-ins) may not work. It took a lot of effort to get the shared libraries to work so dynamic devices have just not been tested yet by our core developers (Andrew Roach and Arjen) with access to MinGW/MSYS. Historically, Arjen has had difficulty getting the MinGW/MSYS approach to work with MS Visual C++ (the windows proprietary compiler) so he felt there was some reason to continue with the bare windows approach for those who preferred that compiler to gcc, but there are lots of configuration issues which he hopes to solve (just for that platform) with Jim. Robert, if you have found some way to get MS Visual C++ to work with autotools on MinGW/MSYS, please give us your cookbook. I believe that would remove most of the motivation behind the bare windows port and make Arjen's life much easier. 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 __________________________ |