FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server.
Artifacts are archived.
And the 64 bit flavor is available too
Regards,
-Fred
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
On Tue, 2011-11-08 at 22:15 +0100, Frederic Bouvier wrote:
- Mail original -
On 8 Nov 2011, at 19:59, Frederic Bouvier wrote:
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server.
Artifacts are archived.
Brilliant, thanks Fred.
I am still not sure about the
On 9 Nov 2011, at 15:32, Geoff McLane wrote:
In Ubuntu linux, because I do NOT have OSG installed in
any 'standard' place, in my makefg script, I do -
export CXXFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
export CFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
to get terragear-cs to cmake build...
In Ubuntu linux, because I do NOT have OSG installed in
any 'standard' place, in my makefg script, I do -
export CXXFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
export CFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
to get terragear-cs to cmake build...
Maybe the CFLAGS is not needed. I did try
On Wed, 2011-11-09 at 17:56 +0100, Frederic Bouvier wrote:
In Ubuntu linux, because I do NOT have OSG installed in
any 'standard' place, in my makefg script, I do -
export CXXFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
export CFLAGS=-DNO_OPENSCENEGRAPH_INTERFACE=1
to get terragear-cs to
Christian Schmitt wrote:
Can confirm the fix as well. It works all as expected. Waiting for your last
feedback now, Martin, before preparing the merge.
I'm pretty certain the crash in 'fgfs-construct' is unrelated, just the
usual issue we already know. Therefore I'd vote to merge the CMake
Martin Spott wrote:
I'm pretty certain the crash in 'fgfs-construct' is unrelated, just the
usual issue we already know. Therefore I'd vote to merge the CMake
branch - just in case, we'd fix the remaining issues in master.
Done. If someone could remove the cmake branches, that'd be nice. :)
On 8 Nov 2011, at 09:57, Christian Schmitt wrote:
Done. If someone could remove the cmake branches, that'd be nice. :)
I'll do so, thanks for the merge.
Onwards with fixing the fgfs-construct crashes!
James
--
Hi,
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server. Artifacts are
archived.
Regards,
-Fred
--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
Fred wrote:
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server. Artifacts are
archived.
Wow, thanks a lot!! I've been waiting for that ever since 2009 :)
Gijs --
On 8 Nov 2011, at 19:59, Frederic Bouvier wrote:
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server. Artifacts are
archived.
Brilliant, thanks Fred.
James
--
RSA(R) Conference 2012
Save $700 by Nov 18
- Mail original -
On 8 Nov 2011, at 19:59, Frederic Bouvier wrote:
FWIW, I added a TerraGear-Win-Cmake task to the Jenkins Server.
Artifacts are archived.
Brilliant, thanks Fred.
I am still not sure about the right method to exclude OSG from the build.
I added
James Turner wrote:
This is fixed now, though I don't really understand how it ever
worked - rawdem.c wasn't checking a particular return code nicely,
now it does.
Thanks a lot, things are looking much better now ! I'll perform a few
more tests and will report back.
In the meantime we
On 7 Nov 2011, at 11:33, Martin Spott wrote:
Thanks a lot, things are looking much better now ! I'll perform a few
more tests and will report back.
In the meantime we managed to established a method to reliably create
topologically clean !! CORINE land cover from the publicly available
On Mon, Nov 7, 2011 at 12:33 PM, Martin Spott martin.sp...@mgras.net wrote:
James Turner wrote:
This is fixed now, though I don't really understand how it ever
worked - rawdem.c wasn't checking a particular return code nicely,
now it does.
Thanks a lot, things are looking much better now !
Martin Spott wrote:
Thanks a lot, things are looking much better now ! I'll perform a few
more tests and will report back.
Can confirm the fix as well. It works all as expected. Waiting for your last
feedback now, Martin, before preparing the merge.
In the meantime we managed to
On 3 Nov 2011, at 18:51, James Turner wrote:
... going to be something really obscure when we track this down, I guess
This is fixed now, though I don't really understand how it ever worked -
rawdem.c wasn't checking a particular return code nicely, now it does.
James
On 2 Nov 2011, at 19:48, Martin Spott wrote:
Fixed now, at least, it generated a ton of .dem files for me.
Really ? And you're on simgear/next and terragear-cs/cmake-integration
without local changes ?
With some local changes to Simgear/next, but I am 'fairly sure' they don't
relate to
James Turner wrote:
On 2 Nov 2011, at 19:48, Martin Spott wrote:
Fixed now, at least, it generated a ton of .dem files for me.
Really ? And you're on simgear/next and terragear-cs/cmake-integration
without local changes ?
With some local changes to Simgear/next, but I am 'fairly sure'
James Turner wrote:
With some local changes to Simgear/next, but I am 'fairly sure' they don't
relate to path/file/string handling. (Some changes in the SGOceanTile
handling)
I just tested this as well (without your fix) and it works here too. Even
when using Martin's pathnames.
Christian Schmitt wrote:
Martin: Can you tell me under which OS this is happening? So I can try to
reproduce it in a VM.
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
Martin.
--
Unix _IS_ user friendly - it's just selective
Martin Spott wrote:
Christian Schmitt wrote:
Martin: Can you tell me under which OS this is happening? So I can try to
reproduce it in a VM.
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
I guess it matters, because I get exactly
Martin Spott wrote:
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
Ok, I observed the following: compiling the raw2ascii as Release leads to
the error (on Debian). When compiling as Debug it works here.
Chris
On Thu, Nov 3, 2011 at 8:19 AM, Christian Schmitt wrote:
Martin Spott wrote:
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
Ok, I observed the following: compiling the raw2ascii as Release leads to
the error (on Debian). When compiling
On 3 Nov 2011, at 13:19, Christian Schmitt wrote:
That's stock Debian 6 alias Squeeze, the current stable, GCC-4.4.5 and
Glibc-2.11.2, if it matters,
Ok, I observed the following: compiling the raw2ascii as Release leads to
the error (on Debian). When compiling as Debug it works here.
James Turner wrote:
I've pushed a fix to Simgear, updated the tests, and now I can run hgtchop
happily with latest simgear and terragear.
Not only can I hgtchop, but also build scenery chunks again. So from my
point of view the problems are solved. Are there any objections against
pushing
Christian Schmitt wrote:
Not only can I hgtchop, but also build scenery chunks again. So from my
point of view the problems are solved. Are there any objections against
pushing the changes to master?
Yes, raw2ascii doesn't work with both simgear and terragear-cs
HEAD and therefore demchop
Martin Spott wrote:
Yes, raw2ascii doesn't work with both simgear and terragear-cs
HEAD and therefore demchop is still untested. I'll provide a test
case as soon as time permits - spare time is a bit tight these days.
Ok, try this - get the data files from:
On 2 Nov 2011, at 18:33, Martin Spott wrote:
In normal operation, raw2ascii should almost immediately start
writing lots of files to ${WORKDIR}/SRTM-30-ASCII/e020n90/, but with
current simgear/terragear-cs I'm just getting an insane number of
lines:
Thanks Martin, will take a look.
James
On 2 Nov 2011, at 18:51, James Turner wrote:
In normal operation, raw2ascii should almost immediately start
writing lots of files to ${WORKDIR}/SRTM-30-ASCII/e020n90/, but with
current simgear/terragear-cs I'm just getting an insane number of
lines:
Thanks Martin, will take a look.
Fixed
James Turner wrote:
On 2 Nov 2011, at 18:51, James Turner wrote:
In normal operation, raw2ascii should almost immediately start
writing lots of files to ${WORKDIR}/SRTM-30-ASCII/e020n90/, but with
current simgear/terragear-cs I'm just getting an insane number of
lines:
Thanks Martin,
Christian Schmitt wrote:
[...] These changes are not yet in the master tree, but can be tested in the
topics/cmake-integration branch. Please do so, if possible, so we can iron
out any showstoppers.
Apparently directory path handling has been changed recently in a way
which prevents
On 26 Oct 2011, at 13:13, Martin Spott wrote:
Apparently directory path handling has been changed recently in a way
which prevents 'terrafit' from recursively walking the given directory
tree.
This issue is with cmake-integration/CMake, cmake-integration/Autoconf
but master/Autoconf is
Martin Spott wrote:
Apparently directory path handling has been changed recently in a way
which prevents 'terrafit' from recursively walking the given directory
tree.
This issue is with cmake-integration/CMake, cmake-integration/Autoconf
but master/Autoconf is fine. I'm also observing a
On 26 Oct 2011, at 13:34, Martin Spott wrote:
I was interrupted when writing the above As an addition I'd
propose to separate the de-PLIB-ifying from the 'cmake-integration'
into a separate branch/topic/whatever because the move to CMake as a
build system appears to be successful.
A
On Wed, 2011-10-26 at 13:19 +0100, James Turner wrote:
On 26 Oct 2011, at 13:13, Martin Spott wrote:
Apparently directory path handling has been changed recently in a way
which prevents 'terrafit' from recursively walking the given directory
tree.
This issue is with
James Turner wrote:
Can you describe / give me a minimal test setup?
Difficult, because 'hgtchop' doesn't work any more either, not even
with terragear-cs/master ;-)
Try this one for the preparational step - adapt from my setup:
DATADIR=${HOME}/archive/GIS/GISData/SRTM/version2_1/HGT/SRTM3
Geoff McLane wrote:
An error something like -
'do not know how to make main.c from main.o'
which I did NOT understand... seems reversed!
And why 'main.c', since the Makefile.am shows
only -
raw2ascii_SOURCES = main.cxx rawdem.c rawdem.h
There is no main.c here???
Hi,
this is caused
James Turner wrote:
A fair suggestion! I originally combined them because it was easier not to
worry about PLIB when creating the CMake files, but I wasn't expecting the
slightly-complex changes to de-PLIB the file handling code.
Let me see how hard it would be, to un-pick the changes.
On Wed, 2011-10-26 at 15:38 +0200, Christian Schmitt wrote:
Geoff McLane wrote:
An error something like -
'do not know how to make main.c from main.o'
which I did NOT understand... seems reversed!
And why 'main.c', since the Makefile.am shows
only -
raw2ascii_SOURCES = main.cxx
James Turner wrote:
Can you describe / give me a minimal test setup?
I'm really running out of ideas and my buget of testing time for today
(maybe this week) is exhausted. I've tested various pairings of
'simgear' and 'terragear-cs', unfortunately without getting a 'hgtchop'
creating
On 26 Oct 2011, at 18:43, Martin Spott wrote:
I've tested various pairings of
'simgear' and 'terragear-cs', unfortunately without getting a 'hgtchop'
creating subdirectories and/or files. Anyhow I'd like to hear from
others being more successful with using recent versions of the
Hi there,
maybe you have noticed some exceptionally high activity in recent days/weeks
on the Terragear repo. Well, there is one particular reason for it: It now
supports the cmake build system and, as of today, does no longer depend on
plib. These changes are not yet in the master tree, but
43 matches
Mail list logo
