Activity for Geoff
-
Geoff committed [03ed61] on FlightGear - Flight Simulator - FlightGear
Use CMAKE_MSVCIDE_RUN_PATH to allow the add_custom_target to run
-
Use SGTimeStamp::sleepForMSec(55) to replace sleep/Sleep
-
Add EXPAT library to cmake
-
Add EXPAT x64 files
-
callers already compensate for year-from-1900 and mont-start-from-0
-
ignore *.bak, and temp*
-
ignore *.bak, and temp*
-
Adjust installWinDeps.bat to use 'windows-3rd-party' submodule
-
ignore *.bak, and temp*
-
Add a batch to install Boost
-
Merge branch 'next' of ssh://git.code.sf.net/u/geoffmc/fgmeta into next
-
Adjust installWinDeps.bat to use 'windows-3rd-party' submodule
-
ignore *.bak, and temp*
-
Add a batch to install Boost
-
ignore *.bak, and temp*
-
Merge branch 'next' of ssh://git.code.sf.net/u/geoffmc/fgmeta into next
-
A minor MSVC 2019 build fix
-
Revert back to upstream CMakeLists.txt
-
B #14 - fix to compile in all distros
-
Revert back to upstream CMakeLists.txt
-
Merge branch 'master' of ssh://git.code.sf.net/u/geoffmc/fgms-fork
-
B #14 - fix to compile in all distros
-
Merge branch 'master' of ssh://git.code.sf.net/u/geoffmc/fgms-fork
-
I'm a bit confused, ... Sorry if I caused that... not intended.. ... duplicate what we already do? Well, yes and no... We do already do it for the test suite... this MR does, part of, that for 'fgrcc'... nothing more... Single purpose, clear, no duplication? An alternative, offered in my first patch, is to include the cmakemodule, and call setup* again... not recommended, but works, as Ron reported... What else can I add... works for me... I think it a good patch, otherwise no PR... just discussion......
-
For MSVC set runtime PATH, to run fgrcc exe
-
Use CMAKE_MSVCIDE_RUN_PATH to allow the add_custom_target to run
-
Merge branch 'next' of ssh://git.code.sf.net/u/geoffmc/fgmeta into next
-
Begin updating README, in 'next'
-
Merge branch 'next' of ssh://git.code.sf.net/u/geoffmc/terragear into next
-
Merge remote-tracking branch 'upstream/next' into next
-
Add a batch to install Boost
-
Adjust installWinDeps.bat to use 'windows-3rd-party' submodule
-
ignore *.bak, and temp*
-
Merge branch 'next' of ssh://git.code.sf.net/u/geoffmc/fgmeta into next
-
Begin updating README, in 'next'
-
Merge branch 'next' of ssh://git.code.sf.net/u/geoffmc/terragear into next
-
In 0.13.4, a quick Window compile test found I needed the following patch - diff --git a/CMakeLists.txt b/CMakeLists.txt index 82361cc..751ca2b 100755 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -88,6 +88,7 @@ if(WIN32) configure_file( "${CMAKE_SOURCE_DIR}/config.h.msvc" "${CMAKE_BINARY_DIR}/config.h" COPYONLY) file(WRITE "${CMAKE_BINARY_DIR}/unistd.h" "/* dummy unistd.h for windows */") else(WIN32) + set ( EXTRA_FLAGS "-std=c++11" ) if(ENABLE_DEBUG_SYMBOLS) list(APPEND EXTRA_FLAGS "-g") endif(ENABLE_DEBUG_SYMBOLS)...
-
Thanks for the feedback Hamza... Yes, I can see your Makefile uses commit 508376d79, which is indeed master, default branch, 0.13.2, so no problem there... And yes I can see the LibCLI somehow failed, and agree we do not exactly know the problem, since it currently works in most distros, but think my cmake.1 branch is better cmake wording anyway, and clears up a WIN32 only block... I have now tested it in Windows, and 2 Linux, so this seems to work for all... You will note I renamed the local static...
-
Have pushed that change, plus a small WIN32 only change, to the cmake.1 branch. This branch is based on master... $ cd fgms-src $ git pull $ git checkout cmake.1 Would appreciate you, and others testing and reporting... thanks... OT: A little off topic, but related... When I look at the repo branches... maybe I missed, or have forgotten! which branch is current. In addition to the default master, there is 0.13.2 which is the closest to the current master except for a comment update, and then there...
-
B #14 - fix to compile in all distros
-
Sorry to hear you are having OpenWRT compile problems... I have no problem cross-compiling the fgms-src in a raspberrypi machine, armv7l, running Raspbian GNU/Linux 8.0 (jessie)... and of course there are no other unix/linux reports of a compile failure in other distributions... To me there seems a problem in each of the list(APPEND add_LIBS <proj>) lines, in that each of the projects a prefixed with -l<proj>, if NOT WIN32... in all other cmake projects I work with this is not required... I think...
-
Yes, I just notice my build script, which includes an option -DCMAKE_INSTALL_PREFIX=/path is completely ignored... Have you tried adding an option -DUSER_INSTALL_PREFIX=/some/path? This seems to work for me... But certainly agree it is a bit confusing...
-
Begin updating README, in 'next'
-
add default.x64 for vcpkg ...
-
Start with some config items
-
Looks good James, thanks... Small typo... seems too small to create a MR... ~/fg/next/terragear$ git diff diff --git a/CMakeLists.txt b/CMakeLists.txt index 0b843d8..800786b 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -131,7 +131,7 @@ if (CGAL_FOUND) if (${CGAL_MAJOR_VERSION}.${CGAL_MINOR_VERSION} VERSION_LESS 4.5) set (CGAL_OLD 1) endif () - endif ()) + endif () endif () # check required dependencies And my ShlWapi.lib fix in FindSimGear.cmake went into the scenery/ws2.0 branch, which is...
-
Yeah my first build was all x86, until I discovered the toolset can be set in the environment... I certainly think modifying the Windows registry should NOT be done... that is no setx... requires admin... hence switched to environment... Not sure why you set a path the cmake... we should expect cmake to be correctly installed... A little trick I learned - it seems cmake does not require the year - That is the generator can be used without it, so you just need VCVERS, which is the same as setting...
-
Have shared the fg-from-scratch via a MR - https://sourceforge.net/p/xdraconian-fgscenery/code/merge-requests/1/ ... see comments there... No do NOT set MSVC_3RDPARTY_ROOT at all... is meaningless in the vcpkg system building... Your move of the CGAL up seems to have SOLVED the boost... per the above patch... and if (MSVC AND MSVC_3RDPARTY_ROOT) is FALSE, as it should be... Regrettably you have reintroduced commit 595099, but if James is happy with this polution, then who am I to care...
-
Ideas on fg-from-scratch.cmd - WIP
-
simplify the fg-from-scratch.cmd - WIP
-
YIPEE! it worked... the build at least... with the following minimal patch to cmake, and had a 100% successful build using a slightly modified fg-from-scratch.cmd... thanks... diff --git a/CMakeLists.txt b/CMakeLists.txt index 3e64939..434a339 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -42,11 +42,11 @@ if (MSVC) if (EXISTS ${TEST_3RDPARTY_DIR}) set(MSVC_3RDPARTY_ROOT ${PARENT_DIR} CACHE PATH "Location where the third-party dependencies are extracted") else (EXISTS ${TEST_3RDPARTY_DIR}) -...
-
Hi Scott, Commit 0133f5 - as stated fine with removed boost. And while I generally agree with James comments about geneally moving to C++/C++11 constructs, but in this case there were no other code changes in the file, except for the inconsequential change of 1arcsec or 3arcsec to (1-arc-sec or 3-arc-sec), using return EXIT_FAILURE; instead of exit(-1);, and removing int i, j;, replaced with int j = 0;, so felt such a change from atoi( argv[1] ); to std::stoi(string(argv[1])); was unneccessary, and...
-
Hi Scott, I too have been building TG successfully for years, and want to help Windows users get there without pain ;=)) If you could, it would be great if you split your merge request... there are some great fixes for apt... that is commit 6953a3c6356 should be done... But your change from - -if (MSVC AND MSVC_3RDPARTY_ROOT) to +if (MSVC AND NOT MSVC_3RDPARTY_ROOT STREQUAL "NOT_FOUND") Does not seem to make sense... my understanding of cmake says these are the same, so why make it more complicated?...
-
Concerning finding Boost... Attached is part of my bldlog-1.txt... showing the settings, and finding boost... Doing: 'cmake X:\terragear-fork -G "Visual Studio 14 Win64" -DCMAKE_INSTALL_PREFIX=X:\install\msvc140-64\terragear-fork -DCMAKE_PREFIX_PATH:PATH=Z:\software.x64;X:\3rdParty.x64;X:\install\msvc140-64\OpenSceneGraph;X:\install\msvc140-64\SimGear;F:\Projects\install\msvc140-64\CGAL -DZLIB_ROOT=X:\3rdParty.x64 -DMSVC_3RDPARTY_ROOT=X:\3rdParty.x64 -DBOOST_ROOT=C:\local\boost_1_61_0 -- Selecting...
-
Hi Scott, Thanks for the patch... it is great to see action on TG... Been through your patch... some good, obvious things... always space changes can cloud a review, but not too many... What problem are you having finding Boost? I have none, and do not think we need to add more dependency variables to some of the tools... understanding that might lead to a better, simpler solution... You need to update your TG source... the Shlwapi.lib has already been added... and why another, new var, PLATFORM_LIBS?...
-
Well, if we publish the libs, we're committing to support that API, right? Yes, and no... committed no... like any API can change... per version, if required... That fact that you're undecided if the directory name should be 'tg' or 'terragear' makes me think this is still at the experimental phase! My indecision here is nothing to do with it... I would opts for the shorter tg, but would accept other suggestions... My guess is anyone doing hacking on a new tool, should do it in a fork / clone of...
-
I am experimenting with some tg tools, which needs access to some of the same bucket geometry used by TG Tools... like test-btg... Publishing it would allow others to experiment with improved, different, tg tools... outside the terragear source... for perhaps later inclusion, if the idea works out... experiments... If you do not want to publish the TG libraries, then I wonder why... there is some good stuff in there... very educational on how FG supports world-wide scenery, aka BTG format... the...
-
How do you close this? I suppose I could just push reject I suppose... will get around to deleting the win32-build2 branch eventually...
-
Ah, seems it just takes time to arrive... Since the array.hxx is a very generic name, chose to install in tg... could be terragear, or... Other 2 ar as before...
-
Have created a new merge request, but sf is acting up on me... I get "Oops, looks like something went wrong." when I try to save, or view the MR! Sorry, do not know what's wrong... I create a new branch from scenery/ws2.0 and cherry picked the 2 commit, and add a third, to install the TG array library... used it in an arr_test app I have been trying...
-
win32.x64 msvc14 build and install
-
Add 'Shlwapi.lib' to CORE depends...
-
add MSVC debug version...
-
Install lib Array and header in include/tg
-
Appears 1., was added in commit 7454ed5 Florent Mar 18 2018... thanks... sorry I missed that... Now just need 2. added to FindSimGear.cmake ie Shlwapi.lib, and if you like my preferred 3., 'd' to the gdalchop executable... thanks...
-
Add 'Shlwapi.lib' to CORE depends...
-
Install lib Array and header in include/tg
-
add MSVC debug version...
-
Merge branch 'win32-build2' after rebase
-
Add 'algorithm' to gdalchop.cxx... max std
-
Install lib Array and header in include/tg
-
Just could not beleive pause for 15 seconds... But if that is what it wants, then there is no reason...
-
Still to test out the TG tools built, but this got a relatively clean build... Separated into 3 commits... 1. add algoritm to `gdalchop` had been indicated before... 2. add shlwapi to CORE deps - no brainer 3. add MSVC 'd', for an EXE - prev. reviewed as excessive... Seems minor difference, will aid the Win32.x64 build. against current SG next... Thank you for the consideration... Regards, Geoff.
-
For Win32 MSVC compile, link...
-
Add 'Shlwapi.lib' to CORE depends...
-
add MSVC debug version...
-
Add 'algorithm' to gdalchop.cxx... max std
-
Win32 API Sleep requires windows.h include
-
But James offers a cross-ported SG wrapper which is better... SGTimeStamp::sleepForMSec(55); See next PR, but sf timeout on merge of msvc-build2... But anyway closing this...
-
Use SGTimeStamp::sleepForMSec(55), in place of sleep()/Sleep()
-
Use SGTimeStamp::sleepForMSec(55) to replace sleep/Sleep
-
Win32 API Sleep requires windows.h include
-
Win32 API, like Sleep, needs windows.h include
-
Hi Oliver, Concerning branch 1.0.0, and a MSVC 14 build... Thanks for all the changes... mainly everything was good, but still ran into a few more... The MS compiler reads all decimal as a double, unless an 'F' or 'f' is appended... so this was my first change - -constexpr float SGMISC_PI { 3.1415926535 }; +constexpr float SGMISC_PI { 3.1415926535f }; Normally this is a 'warning' which can be suppressed, but with constexpr this becomes an error... There remains several other warnings of this type,...
-
Building branch 1.0.0 in Windows with MSVC 14
-
Add MSVC debug EXE to cmake
-
Add MSVC debug EXE to cmake
-
Add msvc-debug exes
-
Add msvc-debug exes
-
VOTE flightgear
-
More CMakeLists.txt changes for WIN32 build
-
More changes to build in WIN32
-
Fixes to build branch 1.0.0 in WIN32 with MSVC14
-
[COMPAT]: small fixes to build in Windows with MSVC14.
-
Suggestions for web status page
-
Final merge branch '0.12.0' into master...
-
WIN32 FIX: Change 'not' to '!'
-
Merge branch '0.12.0' into 'master'
-
Ignore all 'build*/*' folders
-
VOTE: flightgear
1 >
