On 2009-03-10 20:07-0700 Alan W. Irwin wrote:
> To finish up this effort, I plan to rename get-drv-info as test-drv-info and
> make a series of tests comparing its output with the *.rc files that are
> configured by CMake.
DONE (revision 9725). The TEST_DYNDRIVERS option is ON by default and is
On 2009-03-06 08:11-0800 Alan W. Irwin wrote:
> On 2009-03-06 07:17- Andrew Ross wrote:
>
>> On Wed, Mar 04, 2009 at 07:37:53PM +, Andrew Ross wrote:
>>> On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote:
Instead of this approach, I think we should simply store those .rc
On 2009-03-06 07:17- Andrew Ross wrote:
> On Wed, Mar 04, 2009 at 07:37:53PM +, Andrew Ross wrote:
>> On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote:
>>> Instead of this approach, I think we should simply store those .rc
>>> files in the drivers subdirectory of the source tree
On Wed, Mar 04, 2009 at 07:37:53PM +, Andrew Ross wrote:
> On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote:
> > On 2009-03-04 10:58- Andrew Ross wrote:
> >
> >> Thinking about it, get-drv-info is only extracting symbols for the
> >> installed
> >> drivers which are in the source
On 2009-03-04 19:37- Andrew Ross wrote:
> On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote:
>> On 2009-03-04 10:58- Andrew Ross wrote:
>>
>>> Thinking about it, get-drv-info is only extracting symbols for the installed
>>> drivers which are in the source code anyway. There is no
On Wed, Mar 04, 2009 at 09:18:36AM -0800, Alan Irwin wrote:
> On 2009-03-04 10:58- Andrew Ross wrote:
>
>> Thinking about it, get-drv-info is only extracting symbols for the installed
>> drivers which are in the source code anyway. There is no reason we couldn't
>> have some alternative way of
On 2009-03-04 10:58- Andrew Ross wrote:
> Thinking about it, get-drv-info is only extracting symbols for the installed
> drivers which are in the source code anyway. There is no reason we couldn't
> have some alternative way of doing this using cmake or some scripting which
> would not rely on
On Tue, Mar 03, 2009 at 03:44:45PM -0800, Alan Irwin wrote:
> On 2009-03-03 12:49- Andrew Ross wrote:
>
> > On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote:
> >> [...]In sum, my advice [to Thomas was] to stick with CMake (since we
> >> should be able to give
> >> you some help in t
On Tue, Mar 03, 2009 at 03:44:45PM -0800, Alan Irwin wrote:
> On 2009-03-03 12:49- Andrew Ross wrote:
>
>> On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote:
>>> [...]In sum, my advice [to Thomas was] to stick with CMake (since we should
>>> be able to give
>>> you some help in that c
On 2009-03-03 17:59-0600 Thomas Stover wrote:
>
>>>
>>> The current stumbling block for the cairo drivers is that they use
>>> pkg-config to get the correct paths and libraries to link in. This won't
>>> work on a cross-compiled environment unless you provide suitable
>>> pkg-config
>>> files fr
>>
>> The current stumbling block for the cairo drivers is that they use
>> pkg-config to get the correct paths and libraries to link in. This won't
>> work on a cross-compiled environment unless you provide suitable
>> pkg-config
>> files from a cross-compiled version of cairo. This should be po
On 2009-03-03 12:49- Andrew Ross wrote:
> On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote:
>> [...]In sum, my advice [to Thomas was] to stick with CMake (since we should
>> be able to give
>> you some help in that case, and CMake skill with a normal build environment
>> and also a
On Mon, Mar 02, 2009 at 11:16:37AM -0800, Alan Irwin wrote:
> On 2009-03-02 11:38-0600 Thomas Stover wrote:
>
> > Thanks for the input on cross compiling with cmake. Using the latest
> > version
> > of cmake, and the documentation I made a number of attempts to use mingw to
> > build a win32 pl
Hi,
On 02.03.2009, at 22:57, Alan W. Irwin wrote:
> On 2009-03-02 14:57-0600 Thomas Stover wrote:
>
>> Is there an "official" precompiled release for win32 and/or win64?
>
> That has been discussed since it is fairly straightforward to do that
> with CMake, but it hasn't actually happened yet.
I
On 2009-03-02 14:05-0600 Thomas Stover wrote:
> Alan W. Irwin wrote:
>> Specifically, build just the plplot C library (with libqhull and freetype
>> dropped to eliminate those dependencies and with no dynamic drivers to
>> eliminate the dependence on dynamic loading libraries)
>
> What features g
Is there an "official" precompiled release for win32 and/or win64? If
that were the case I would just use that, and bring it into my cross
environment. On the other hand, if the standard installation is for one
is to build their own for maximum tool chain & platform compatibility,
then cross c
On 2009-03-02 14:57-0600 Thomas Stover wrote:
> Is there an "official" precompiled release for win32 and/or win64?
That has been discussed since it is fairly straightforward to do that
with CMake, but it hasn't actually happened yet.
Alan
__
Alan W. Irwin
Astronomical re
Hi Alan and Thomas,
>
> Once you get that first simple cross-build working properly, then I think
> the next step is to figure out what to do with dynamic devices. That
> does
> work on MinGW so it should be straightforward to get it to work for a
> Linux
> cross-build for MinGW, but I am not fa
I have no idea why this works, but it seems to! All I changed is the
data dir. This is astonishing. Surely there must be some problems that
show up later. I think I'm missing support for some major stuff - were
does this nearest neighbors library come into the picture? Never the
less, here is a
On 2009-03-02 11:38-0600 Thomas Stover wrote:
> Thanks for the input on cross compiling with cmake. Using the latest version
> of cmake, and the documentation I made a number of attempts to use mingw to
> build a win32 plplot from a linux host. By the end of the day Friday I
> reached the concl
Correction, it works. I just had to properly set the hard coded data
directory. Actual cross compile test comming soon...
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the b
Hi Thomas,
just for the records, since you already figured it out yourself:
> *** PLPLOT ERROR, IMMEDIATE EXIT ***
> Unable to either (1) open/find or (2) allocate memory for the font file
> Program aborted
Here, PLplot can't find the Hershey fonts, which are in the PLplot data
directory. Actuall
Alan W. Irwin wrote:
> I think doing your own specific Makefile based build system for PLplot
> would
> work, but I also think it would take a rather large effort on your
> part with
> no beneficial networking effects at all (nobody else would use your
> approach
> so you could gain little help
Thanks for the input on cross compiling with cmake. Using the latest
version of cmake, and the documentation I made a number of attempts to
use mingw to build a win32 plplot from a linux host. By the end of the
day Friday I reached the conclusion that although this is probably
possible using th
24 matches
Mail list logo
