On Dec 12, 2007 8:28 AM, Karl Glazebrook <[EMAIL PROTECTED]> wrote: > I am not sure I understand the discussion about 'RGB support' but I > will comment on this. >
I downloaded your SciKarl v0,12/ppc and ran "demo cartographic". I got an error message saying that RGB was not enabled in PGPLOT and the (MODIS) map background was rendered in grey scale on the screen. Do you have the RGB patches in your PGPLOT build? > I would very much like to have something link SciKarl on Linux. I > imagine something that would install under it's own directory tree (/ > usr/local/pdl or ~/pdl) where you would source a set up file and then > it would all work. It's on my mental list of round tuits but being a > busy Prof. I am can not predict when if ever i could find some time to > play with this! The little time I budget for open source development is taken by GrADS until sometime in the Spring. > > If there are any volunteers I'd be happy to discuss and give > gratuitous advice. > > One thing that is unclear to me is whether a single binary build could > serve all of linux given the diversity. - Any comments? > My experience building GrADS (a stand alone binary with an increasing number of external dependencies, see the "Build Notes" under http://opengrads.org/wiki/index.php?title=OpenGrADS_Documentation) is that you can have a generic Linux binary provided that you link in your dependencies statically or put the relevant shared libraries in your LD_LIBRARY_PATH. If you look at commercial packages such as IDL, intel and other commercial compilers, you will notice that this precisely how they do it. In the case of GrADS I've been able to use a Red Hat built i586 binary on Mandriva, Ubuntu, Suse, Altix, that is, on a variety of i586, x86_64 and ia64 platforms alike. It is doable, with a bit of fine tuning. Of course, up to a limit: very ancient distros may have some form of ABI incompatibility which will not run recent binaries. One of my concerns is the incompatibilities that may arise from different versions of perl, thread issues and the like. I personally do not have much experience developing perl extensions. It is likely that one may not have a "universal" Linux binary, but specific ones for a given perl version, threading options, and platform (i586, x86_64, ia64). If I was doing it I'd mimic what I have done for the GrADS "supplibs" (supplemental libraries, what we call the external dependencies), http://opengrads.org/wiki/index.php?title=Supplemental_Libraries_%28Supplibs%29 for the PDL specific dependencies. The idea here is that you download a huge source tarball, untar it and type: % gmake install --prefix=/path/to/some/dir and some time later you will have a mini static distro under the chosen prefix. The supplibs include their own pkconfig which helps ensure that internal consistency of the build. When configuring the GrADS sources prior to building we give the supplib prefix and it first looks there for its dependencies. Since the building issues are usually associated with the supplibs, distributing binary supplibs greatly simplifies the build process. And also, you can keep the supplibs sources under strict configuration management, sharing the same bugs across all the platforms. And make no mistake: maintaining the supplibs is a job, albeit a part-time one. The semi-binary distribution option (distributing pre-compiled binaries of the supplibs, and building PDL on the fly from there) may be a better option for PDL as it would ensure a great compatibility with the underlying perl binary. It can also help creating multi-platform *distributed* nightly builds and regression tests. I believe all this can be made to work but it will need some experimentation and fine tuning, as usual. But the final convenience pays off in the end and may help improve PDL adoption. One final thought. One should still strive to get complete PDL functionality within the major Linux distros. The PDL (semi-?) binary distribution option should be a fallback, and the means to quickly get to the latest stable release (hopefully thoroughly tested as well). And many thanks for making SciKarl available. Arlindo -- Arlindo da Silva [EMAIL PROTECTED] _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
