On Thursday 03 Oct 2013 11:15:41 Alan W. Irwin wrote:
> 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.
It's in an add_custom_command statement, so VERBATIM sounds like the option
I'm looking for. In fact from the documentation it sounds like one should
always use that to ensure that variables behave as one would normally expect.
I'll give it a go.
> > 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.
Orion, do you have any preferences on this?
Thanks
Andrew
------------------------------------------------------------------------------
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
