> 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
http://p.sf.net
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
> > 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 need
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...
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
- 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 -DNO_OPE
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
> 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 --
RS
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
__
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
--
RSA(
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. :
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:
> 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 establi
On Mon, Nov 7, 2011 at 12:33 PM, Martin Spott 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 !
Indeed, valg
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
>
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 mana
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 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
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
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
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 e
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 abo
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.
gl
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 'fai
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
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:
>>
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
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.
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:
ftp://ftp.ihg.uni-dui
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 "
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 t
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
> 'terra
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 subdirect
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_SOURC
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.
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
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
WO
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 cmake-integ
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.
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: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
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 'terr
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 ca
43 matches
Mail list logo
