On 2013-07-05 16:08- Schwartz, Steven J wrote:
> Here's the top of the (correct) linux eps:
>
> %!PS-Adobe-3.0 EPSF-3.0
> %%BoundingBox: 1 0 596 842
> %%Creator: Qt 4.8.2
> %%CreationDate: Fri Jul 5 16:40:03 2013
> %%Orientation: Landscape
> ... snip ...
> /pageinit {
> % 210 *297 mm (landsca
Dear All,
Schwartz, Steven J wrote on 2013-07-04:
>>> The qt ps and pdf files always generate a portrait page with the
>>> plot spilling off the right hand edge of the page.
>>
>> On Linux I have just run
>>
>> examples/c/x01c -dev epsqt -o test.eps
>>
>> and
>>
>> examples/c
Alan,
> On Wed, 26 Jun 2013 11:32:28 +
> "Schwartz, Steven J" wrote:
>> Alan, Arjen, et al.,
... snip
> My experience is MinGW-4.7.x is more reliable than previous versions
> so I attribute the qt device driver run-time crashes you are
> encountering to your
> (forced) use of MinGW-4.4.
>
>Point taken, but note binary distributors would also not want to
>alienate the huge numbers of MinGW users as well. MinGW-4.7.2 has
>been averaging 20,000 downloads of its core package per month for the
>7 months since its release. And MinGW-4.6.2 has had 800 thousand (!)
>downloads of its core
On 2013-06-28 09:44- Schwartz, Steven J wrote:
> There is a potential snag in your approach which is that the
build-projects wrapping of a project's own autotools/whatever is only
as good as that project's build strategy. Good, relatively small
projects are probably ok. I've read tales of woe
Alan
Apologies for top-posting (from my phone).
There is a potential snag in your approach which is that the build-projects
wrapping of a project's own autotools/whatever is only as good as that
project's build strategy. Good, relatively small projects are probably ok. I've
read tales of woe a
On 2013-06-27 15:05-0700 phil rosenberg wrote:
> One question though. If a binary version is built with gcc, can it be used by
> Visual Studio or vica-versa?
In general, I think the answer is no. It is best to build everything needed
with a
consistent tool chain.
> If PLPlot wants to increase
I would just like to add to the support for a binary distribution. Just a few
weeks ago I was exchanging email with the writers of wxAstroCapture and
mentioned PLPlot. They had heard of it but found it too difficult to build so
used something else. I remember when I first attempted to compile it
Hi Steve:
On 2013-06-26 13:48- Schwartz, Steven J wrote:
> My impression is that the most difficult binaries are in the
*nix world. It seems easier to create windows and mac binaries that
will run without being too fussy about the version of everything else
that is installed, but I have less
Hi Steve:
Thanks for your contributions to this thread. More below
in context.
On Wed, 26 Jun 2013 11:32:28 +
"Schwartz, Steven J" wrote:
> Alan, Arjen, et al.,
>
> I have been following this thread, and the parallel ones re Cygwin build and
> also build_project, with some interest. We
Arjen,
Arjen Markus wrote on 2013-06-26:
> Note, when I wrote "minimal distribution" I was thinking more along
> the lines of minimzing the amount of work to build the distribution.
Understood, but these two are not completely unrelated concepts, or at least
they minimise differ
Hi Steven,
interesting, my experience with Qt is very limited, but it
definitely is something to keep in mind - as are your
other
experiences.
Note, when I wrote "minimal distribution" I was thinking
more along the lines of minimzing the amount of work to
build the distribution. Besides drivers
Alan, Arjen, et al.,
I have been following this thread, and the parallel ones re Cygwin build and
also build_project, with some interest. We ship a binary Windows version of our
QSAS software (which includes the Qt libraries and a somewhat stripped-down
version of plplot which only drives our o
Hi Alan,
I am almost there: small batch file to define a bunch of
environment variables.
There is one thing that I do not quite like:
The colour map files need to be installed in
"c:\program files (x86)\plplot\share\plplot5.9.9"
This is slightly annoying because this requires
administrator
rig
Hi Alan,
on MinGW the default value for CPACK_INSTALL_PREIX is now
"C:/Program Files(x86)/plplot". It is the first part,
"C:",
that causes trouble.
The trouble I had with MinGW/MSYS was rather strange -
whenever I typed "make" in an MSYS-box, it ran the
MicroSoft
version of "make". When I typed
On 2013-06-25 09:52+0200 Arjen Markus wrote:
> An absolute path as the install prefix is not acceptable,
> I am afraid: CPack creates a directory tree under the
> build directory that reflects exactly the directory of
> the installation. That means that it would attempt to
> create a subdirectory
On Mon, 24 Jun 2013 12:11:52 -0700 (PDT)
"Alan W. Irwin" wrote:
> Hi Arjen:
>
> This is an extremely interesting topic for me. More
>below in context.
>
Hi Alan, Andrew,
I have been experimenting a bit with CPack and I ran into
a bunch of small problems but nothing that we should not
be ab
I agree with Alan's caution over this, however if we _can_ manage a windows
binary distribution then that would immeasurably widen the appeal of plplot.
The fact is that plplot is a complex beast to build given the dependencies and
Windows users tend to be far less used to this kind of thing th
Hi Arjen:
This is an extremely interesting topic for me. More below in context.
On 2013-06-24 14:42+0200 Arjen Markus wrote:
> We have discussed the possibility of binary distributions in the past,
> but there never was an opportunity as far as I remember to really do
> something about it. CMak
19 matches
Mail list logo
