On 2013-10-03 15:54+0100 Andrew Ross wrote:
>
> I've been working on updating the Debian packages for the 5.9.10 release and
> this has thrown up a couple of issues along the way that I think are worthy of
> some wider discussion.
>
> 1) Since the default version of java on different architectures is different,
> there is a requirement to use the -source and -target arguments for javac in
> order ensure a consistent version requirements across all architectures.
> Currently there is no way to pass additional command line options to the java
> compiler, unlike most other languages. The cmake support for java (which we
> don't currently fully use) does have a CMAKE_JAVA_COMPILE_FLAGS option which I
> tried to implement (basically added this to the javac command line then set it
> with -DCMAKE_JAVA_COMPILE_FLAGS="-source 1.5 -target 1.5". This should (?)
> work. I've tried various ways of quoting this arguments and I either end up
> with the whole lot being treated as a single argument to javac (which doesn't
> work) or it gets treated as a list, with semicolons being inserted between the
> options (which also doesn't work). What is the "preferred" way of dealing with
> variables like this which are actually multiple options? For now I've hacked
> in by patching the custom commands in the CMakeLists.txt files, but a cmake
> variable based approach would be cleaner and less intrusive.
Does this issue show up in either an add_custom_command or add_custom_target
context? If so the combination of using CMake lists (which you
referred to above) and the VERBATIM option to add_custom_* usually seems to
work.
>
> 2) I've been trying to add multiarch support to the packages so different
> versions of the library can be installed on the same machine (e.g. 32 and 64
> bit versions). Debian (and Ubuntu) achieve this by have a /usr/lib/{arch}
> directory for putting libraries in. This is fine, but only 1 version of
> executable binaries can be installed in /usr/bin. The problem arises with the
> tk support where the plserver executable is actually called by the libraries
> and drivers, but not directly by the user. Thinking about this, I think it is
> an ideal candidate for installing in a libexec directory (i.e. somewhere for
> executables called by other executables). I would propose putting it in
> /usr/lib/plplot5.9.10/bin or similar rather than /usr/bin. On multiarch
> systems it would be in /usr/lib/{arch}/plplot5.9.10/bin. This is what I am
> doing for the Debian packages. Do people think this would be a sensible change
> more widely? If so, I'll commit it to svn. I like to keep the changes for the
> Debian packages to a minimum where possible.
I don't have much experience with multiarch so I cannot comment on the
technical issues, but I assume Orion (as Fedora packager) has
multiarch needs as well. So of you two can come to consensus on what
is the best thing to do upstream, then I would certainly have no
objection to you making upstream multiarch changes.
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
__________________________
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Plplot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/plplot-devel
