Geoff
I found the Windows Cmake procedure rather simpler than you (but still much
more complicated than the simple Flightgear single MSVC project).
Here again is the recipe, from my post of 18 Oct, to which you can add my
now infamous step 12a from 19 Oct.
Alan
1. Set up a work directory as
Hi Mathias,
Thanks again for your reply, comments and
suggestions... always very welcome and all taken
constructively. And I hope you understand
I am NOT the one just saying it 'does not work'...
I _AM_ taking the time, trying to understand,
HOW to make the windows cmake GUI work better...
Hi Geoff,
On Saturday, October 29, 2011 18:21:29 Geoff McLane wrote:
> Thank you for your reply and ideas... and
> hope I can answer some things regarding Windows...
> And as usual, sorry in advance that this is so
> long...
So, my disclaimer is that I do not have any win32 system running.
I ju
Hi all,
Just some good news ;=))
After writing a little perl script to 'FIX' the
CMakeCache.txt file, cmake generated the
MSVC build files without my 'cheating' by
setting SIMGEAR_VERSION_OK ;=))
However it outputs some ominous warnings at the end,
and still have to test these build files, b
On Sat, 2011-10-29 at 13:49 +0200, Mathias Fröhlich wrote:
> Hi,
>
> On Friday, October 28, 2011 20:20:55 Geoff McLane wrote:
> > Re: In Windows (XP WIN32) - using CMake GUI
> > =
> >
> > Unfortunately, here not so good ;=(( for building
> > FG. SG was not too bad...
> >
Hi,
On Friday, October 28, 2011 20:20:55 Geoff McLane wrote:
> Re: In Windows (XP WIN32) - using CMake GUI
> =
>
> Unfortunately, here not so good ;=(( for building
> FG. SG was not too bad...
>
> As mentioned, I had to add two options,
> PTW32_STATIC_LIB, to use pthread
Geoff
I hope James listens to you, I have been studiously ignored.
Alan
-Original Message-
From: Geoff McLane
Sent: Friday, October 28, 2011 7:20 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
Re: In Windows (XP WIN32
On Fri, 2011-10-28 at 08:57 +0100, James Turner wrote:
> On 26 Oct 2011, at 19:24, Geoff McLane wrote:
>
> > Maybe, as you have suggested, this is over kill,
> > setting BOTH SIMGEAR_DIR in the environment,
> > AND passing SIMGEAR_INCLUDE_DIR to cmake,
> > and when I feel comfortable, I will elim
On 26 Oct 2011, at 19:24, Geoff McLane wrote:
> Maybe, as you have suggested, this is over kill,
> setting BOTH SIMGEAR_DIR in the environment,
> AND passing SIMGEAR_INCLUDE_DIR to cmake,
> and when I feel comfortable, I will eliminate
> one or the other for further testing...
>
> BUT now I ha
On Tue, 2011-10-25 at 18:47 +0100, James Turner wrote:
> On 25 Oct 2011, at 15:20, Geoff McLane wrote:
> >
> >
> >> need to see the arguments / environment
> >> passed to CMake, to understand why.
> > But in each case I have explicitly given you
> > the exact exports and cmake commands used...
On 25 Oct 2011, at 15:20, Geoff McLane wrote:
>
>
>> need to see the arguments / environment
>> passed to CMake, to understand why.
> But in each case I have explicitly given you
> the exact exports and cmake commands used...
>
> What more do you need?
The problem is you've confused me, wit
On Mon, 2011-10-24 at 14:53 +0100, James Turner wrote:
> On 24 Oct 2011, at 13:17, Geoff McLane wrote:
>
> >
> > In my case I like to be able to compile
> > against different versions of say OSG - like -
> >
> > OSG301=1# stable release 3.0.1 - default
> > OSG283=0# general rele
On 25 Oct 2011, at 09:39, Adrian Musceac wrote:
> Hi James, and thanks for updating the readme. I may be blind or just stupid,
> but I can't find a way of setting CMAKE_PREFIX_PATH in KDevelop that works.
> Adding it to environment variables does not do anything, and cmake fails to
> find the
On Monday, October 24, 2011 16:53:23 James Turner wrote:
>
> Mathias' suggestion also works, BTW - specify CMAKE_PREFIX_PATH, with one
> (or several) paths to search - I tested that this morning and updated the
> README.
>
> As you guessed, manually setting the the detection variables
> (SIMGEAR_
-Original Message-
From: James Turner
Sent: Monday, October 24, 2011 2:53 PM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
As you guessed, manually setting the the detection variables
(SIMGEAR_VERSION_OK, etc) is a bad idea, unless
On 24 Oct 2011, at 13:17, Geoff McLane wrote:
>
> In my case I like to be able to compile
> against different versions of say OSG - like -
>
> OSG301=1# stable release 3.0.1 - default
> OSG283=0# general release 283 - option
> OSG299=0# another development release
> OSG
Hi James,
Thanks for your reply, and from Mathius and
Alan...
> Does that help at all?
Well, there is no doubt I could 'simplify' the
situation by NOT appending an extra path items
after 'install', but I should not have to!
If I wanted such a 'simple' single install path,
why not install tho
developers discussions
Subject: Re: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
Hi All,
HELP needed ;=((
Trying to compile the latest FG git, updated just hours
ago, in Ubuntu 10.04, using CMake...
---snip
CMake Error
at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70
Hi,
On Sunday, October 23, 2011 21:44:53 James Turner wrote:
> I'm not sure *exactly* what you're doing wrong, but in general I would say
> you're over controlling things a little.
>
> I'm not clear why you are installing each component in a subdir of install
> - that's making your life complica
On 23 Oct 2011, at 18:47, Geoff McLane wrote:
> Sorry, what am I doing wrong?
I'm not sure *exactly* what you're doing wrong, but in general I would say
you're over controlling things a little.
I'm not clear why you are installing each component in a subdir of install -
that's making your lif
Hi All,
HELP needed ;=((
Trying to compile the latest FG git, updated just hours
ago, in Ubuntu 10.04, using CMake...
First tried -
.../source$ export OSG_DIR=/home/geoff/fg/fg16/install/OSG301
.../source$ cmake -D CMAKE_BUILD_TYPE=Release -D CMAKE_CXX_FLAGS=-O3 \
-D LIB_POSTFIX= \
-D CMAKE_INS
On Sun, 2011-10-23 at 09:44 +0100, James Turner wrote:
> The special purpose FDMs are disabled by default, it's one line to make them
> enabled by default of course!
>
> Actually, one of my post CMake build plans, is to make all the FDMs
> switchable at build-time, partly because I'm sick of all
On 23 Oct 2011, at 09:31, Erik Hofman wrote:
> CMake worked like a charm but I did notice that the special purpose
> FDM's don't get included anymore. I believe I did see it mentioned in
> the CMake configuration but leaving code out on a development system
> might introduce a chance of bit-rot.
On Sat, 2011-10-22 at 16:03 +0100, James Turner wrote:
> If there's lingering queries about Cmake, or requests on the 'best' way to
> handle the transition, please let me know. Feedback on the README file would
> be appreciated too, or even commits / patches to improve it!
CMake worked like a ch
On 22 Oct 2011, at 16:09, Curtis Olson wrote:
> It might be a bit extra work, but it would be good to take the source.tar.gz
> files that cmake creates, unpack them in a new directory and just make sure
> we can do a clean build from them. This always seems to expose a file or
> two, or a hea
-Original Message-
From: James Turner
Sent: Saturday, October 22, 2011 4:03 PM
To: FlightGear developers discussions
Subject: [Flightgear-devel] CMake, tomorrow (Sunday 23rd)
If there's lingering queries about Cmake, or requests on the 'best' way to
handle the transit
On Sat, Oct 22, 2011 at 10:03 AM, James Turner wrote:
> Hello again,
>
> Barring last-minute objections, I would like to declare CMake 'the' build
> system, from tomorrow onwards. Since my last email I've added a README.cmake
> to flightgear, and I'm working on ensuring the 'make dist' features of
Hello again,
Barring last-minute objections, I would like to declare CMake 'the' build
system, from tomorrow onwards. Since my last email I've added a README.cmake to
flightgear, and I'm working on ensuring the 'make dist' features of automake
are replicated in CMake (via CPack) so when 2.6 tim
28 matches
Mail list logo
