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... > > > > As mentioned, I had to add two options, > > PTW32_STATIC_LIB, to use pthreads (for Win32) > > static, and OSG_LIBRARY_STATIC, to use all > > static OSG libraries... > > Ok, I do not know the win32 build too good: > But why are you using pthreads on win32? > Neither osg nor simgear/flightgear should need this. > And at least for osg, how do you manage to make osg use pthreads on win32? > > Also why do you want to have osg statically linked? > It's possible to build and use osg with just static libs. But the default and > really best supported configuration of osg is using shared libraries. > The basic architecture of model loaders within osg is built around shared > objects dynamically loaded at runtime. So as I saied before, it's possible to > make osg's reader/writers work with static libs, but we do *not* have any > support for that in flightgear/simgear. You would need some scary linker > tricks > or some code changes to make this work and I am not aware of anything in that > corner in flightgear/simgear. > > Also, if you use static osg libraries, linking with them is probably > incomplete within our buildsystem. We assume that once we link against an osg > library this dll already pulls in what it requires for itself. This is not > the > case for static libraries. > > To me this pretty much explaines that huge amount of hand changes you have to > to with cmake. > > I would suggest not to try linking osg with static libs. > Also I would suggest that you do not use pthreads on win32. > > Then, if you still have to do some of these scary changes to cmake like > setting SIMGEAR_VERSION_OK=TRUE, please stop and return to here. > > Mathias >
Hi Mathias, 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... While I nearly always use 'shared' libraries in Ubuntu, when offered, such DLL implementations in Windows are just NOT so good... It means when you want to share the application with some other Windows person, or even copy it to a second, 3rd machine, you have to - (a) pack all the DLLs with the EXE, and you/they need to know how to set it up, or (b) you have to go to whole distance and pass them a Windows installer app, which will handle all this placement for them... using like NSIS, INNO, etc... Moreover even then, usually depending on the MSVC version used, and the runtime chosen, there still remains some incompatibilities even between the various versions of Windows... As you point out, OSG does fully support using static libraries, AND that support INCLUDES pulling in the desired set of plugins... see the USE_OSGPLUGIN(ac); MACRO... AND SimGear/FlightGear includes all this 'static' support, just by defining OSG_LIBRARY_STATIC the OSG macro pulls in the desired set of plugins... So in most ways it is no different, excepts for the massive convenience of not having to be concerned about DLLS being in the right place at runtime... Now whether pthreads is still needed for SG/FG, that I will have to check... maybe it is just some residual, old code... BUT I do notice in the Ubuntu compile/link that pthreads or pthread IS still part of the process, even in the cmake build... maybe this needs to be removed... One of the great things about using static libraries, is that the linker only extracts the required code, and only for any services/functions actually called... So it does no particular harm to link with this or that additional static library, even if nothing is used from it... nothing will be added to the executable... Ok, quickly looking in src/Main/bootstrap.cxx, I can see the code :- #ifdef PTW32_STATIC_LIB // Initialise static pthread win32 lib pthread_win32_process_attach_np (); #endif so, if pthreads is NOT required then this call should be REMOVED from the code. Now back to OSG, I do NOT think the changes I have had to make in the GUI have anything at all to do with whether using shared or static OSG... Yes, it does make a slight difference regarding the plugins, since in the static case, this set of plugins desired MUST be passed to the linker at link time... about 6 or 10 of them... But ok, I am willing and able to deal with that just so I can keep my convenience of using all 'static' libraries, where possible. And this static/shared question has got nothing to do with the big list of both PLIB, SimGear and OSG libraries that MUST get into the MSVC build files... I am lucky I can compare the CMakeCache.txt files from linux and windows... In linux, I can see all the SAME entries are there, like say - OSGTEXT_INCLUDE_DIR:PATH=/home/geoff/fg/fg16/install/OSG301/include OSGTEXT_LIBRARY:FILEPATH=/home/geoff/fg/fg16/install/OSG301/lib/libosgText.so OSGTEXT_LIBRARY_DEBUG:FILEPATH=OSGTEXT_LIBRARY_DEBUG-NOTFOUND but in linux the last entry is left blank, since linux only uses one set of libraries for the single link... But in windows BOTH MUST be filled in, since always there is a Release and a Debug configuration, if you want to build both, which I do... Similarly for SimGear, in linux - SIMGEAR_BUCKET_LIBRARY:FILEPATH=optimized;/media/Disk2/FG/fg17/install/simgear/lib/libsgbucket.a;debug;/media/Disk2/FG/fg17/install/simgear/lib/libsgbucket.a SIMGEAR_BUCKET_LIBRARY_DEBUG:FILEPATH=SIMGEAR_BUCKET_LIBRARY_DEBUG-NOTFOUND SIMGEAR_BUCKET_LIBRARY_RELEASE:FILEPATH=/media/Disk2/FG/fg17/install/simgear/lib/libsgbucket.a But for Windows, if you want to compile the Debug configuration, then that second item must be filled in... Likewise for PLIB - linux PLIB_UL_LIBRARY:FILEPATH=optimized;/usr/lib/libplibul.a;debug;/usr/lib/libplibul.a PLIB_UL_LIBRARY_DEBUG:FILEPATH=PLIB_UL_LIBRARY_DEBUG-NOTFOUND PLIB_UL_LIBRARY_RELEASE:FILEPATH=/usr/lib/libplibul.a Now in linux, I assume all this was done... that is the CMakeCache.txt was built when I ran the $ cmake $FGCM_OPTS so no trouble, once I got some paths right!!! But in windows, EACH of these variable MUST be setup one by one, in the GUI... I have not done the counts exactly, but that is like SimGear 25 x 3 items to setup OSG 8 x 3 items to setup PLIB 7 x 3 items to setup That already 120 items to setup, even BEFORE we add all the other type entries that MUST be dealt with BEFORE you can have MSVC build files generated... At a quick count in windows there are about a total of 328 configuration items to deal with... And here only dealing with FG, but there were less items in simgear, since it is mainly libraries... That is MOST CERTAINLY stressing the capability of any user to NOT make one or two mistakes on the first run ;=)) And certainly in some cases pushing their 'understanding' beyond normal limits... Again nothing to do with whether shared (the default), or static is chosen... RANT begins ;=() I can NOT help feel this is a giant step BACKWARDS for the Windows builder ;=(( In the beginning we had simgear.dsw and flightgear.dsw to load, kept relatively up to date with Curt's venerable am2dsp.pl script... built ONE static simgear.lib, and one flightgear.exe... for years like this... I, and others tried various build systems, especially since those 2 dsw only dealt with SG/FG, and NOT all the other dependents needed in Windows... Then thankfully we got Fred, who does keep his MSVC build files relatively up-to-date, AND provided a 3rdparty download of the dependents provided you agreed with his runtime choices... usually /MD, and again we continued for years... For myself, and a few other users, and not only for SG/FG, I re-wrote am2dsp.pl, into amsrcs.pl, which can easily generate viable dsw/dsp build files for any project using the configure.ac and Makefile.am system... This was good in that it also works for most of the dependent libraries as well, and had some other tools to help if not, like createdsp.pl... And like Fred, I started offering zips of binary dependents, using my choice of runtime, usually /MT... Then came OSG, and cmake... but ok it was not too difficult to absorb one case using cmake, the rest with my amsrcs.pl... and certainly from my perspective stayed ok because OSG and SG/FG supported a 'static' build... Then on 2010/10/19 Jame proposed cmake. His words at the time - "These files are completely orthogonal to the existing autoconf/automake build..." and "My motivation for creating these was my Mac Xcode projects..." and even asking developers to consider updating CMakeFiles.txt when they changed the Makefile.am, like some were already doing for the MSVC vcproj files... But we have moved on and now we are all supposed to go gung-ho only on cmake ;=(( Well I am TRYING to take it in... I _AM_ spending the extra time to understand, especially regarding any limitation, and not so much regarding any extra work needed, since I am sure I will find a way to automate some of that... I have started a work-in-progress page - http://geoffair.org/fg/fgfs-055.htm dedicated to seeing how far I can go with CMake quite specifically in Windows. I know there are enough 'strong' developers in unix/linux to either carry this cmake forward there, or if need be, CAN IT! I understand James, and some others, are Apple MAC, so again sure, the needs there will be dealt with... and really thank him again for the time, effort and dedication he is putting into this cmake push... Not so sure about cygwin, mingw, Kdevelop, and maybe other build systems... since do not use any of these... and have read little... So I am most concerned about what this will mean to windows builders. It is absolutely NOT enough to just say cmake is cross-system-compatible... I am sorry Mathias, this turned into a general RANT ;=(( which has been building up for a while... Certainly not in any way directed at you... And thank you for your ideas on shared versus static, and hope I have in part covered some of what motivates me ;=)) building SG/FG, and trying to make it easier for others to build it... Regards, Geoff. ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
