Thread: [Celestia-developers] Some cleaning up
Real-time 3D visualization of space
Status: Beta
Brought to you by:
cjlaurel
From: Andrew T. <ajt...@go...> - 2012-03-21 19:28:54
|
Hello, I've noticed that the src tree has several Visual C++ 6 projects/makefiles floating around, would anyone object if we got rid of these? There are also several duplicate models: amalthea.3ds/*amalthea.cmod bacchus.3ds/*bacchus.cmod castalia.3ds/*castalia.cmod deimos.3ds/*deimos.cmod epimetheus.3ds/*epimetheus.cmod eros.3ds/*eros.cmod/eros.cms gaspra.3ds/*gaspra.cmod geographos.3ds/*geographos.cmod golevka.3ds/*golevka.cmod halley.3ds/*halley.cmod hyperion.3ds/*hyperion.cmod/hyperion.cms ida.3ds/*ida.cmod janus.3ds/*janus.cmod kleopatra.3ds/*kleopatra.cmod ky26.3ds/*ky26.cmod larissa.3ds/*larissa.cmod pandora.3ds/*pandora.cmod phobos.3ds/*phobos.cmod phoebe.3ds/*phoebe.cmod prometheus.3ds/*prometheus.cmod proteus.3ds/*proteus.cmod/proteus.cms toutatis.3ds/*toutatis.cmod vesta.3ds/*vesta.cmod * indicates use in the files of the data directory Do we actually need to keep all these unused meshes around? Regards, Andrew |
From: Chris L. <cl...@gm...> - 2012-03-22 18:37:31
|
I think it'd be a good idea to get rid of the Visual C++ .mak files. The Visual C++ project file celestia.vcproj is still used by some people though; I'd like to leave it there for now. In the early days of Celestia, 3ds was the only supported model format. When cmod was added, I converted all the meshes to the new format because it loads faster (very little preprocessing required at load time for cmods.) I left the 3ds versions around because 1) they're closer to the original models, and 2) they can be easily viewed and edited in modeling software, whereas cmod files cannot. It shouldn't be necessary to keep the 3ds files around any more. It'd be better to just have a README file giving the original sources of the shape models. Ideally, we'd also commit the scripts required to convert models from their original formats to cmods. --Chris On Wed, Mar 21, 2012 at 12:28 PM, Andrew Tribick <ajt...@go...>wrote: > Hello, > > I've noticed that the src tree has several Visual C++ 6 > projects/makefiles floating around, would anyone object if we got rid > of these? > > There are also several duplicate models: > > amalthea.3ds/*amalthea.cmod > bacchus.3ds/*bacchus.cmod > castalia.3ds/*castalia.cmod > deimos.3ds/*deimos.cmod > epimetheus.3ds/*epimetheus.cmod > eros.3ds/*eros.cmod/eros.cms > gaspra.3ds/*gaspra.cmod > geographos.3ds/*geographos.cmod > golevka.3ds/*golevka.cmod > halley.3ds/*halley.cmod > hyperion.3ds/*hyperion.cmod/hyperion.cms > ida.3ds/*ida.cmod > janus.3ds/*janus.cmod > kleopatra.3ds/*kleopatra.cmod > ky26.3ds/*ky26.cmod > larissa.3ds/*larissa.cmod > pandora.3ds/*pandora.cmod > phobos.3ds/*phobos.cmod > phoebe.3ds/*phoebe.cmod > prometheus.3ds/*prometheus.cmod > proteus.3ds/*proteus.cmod/proteus.cms > toutatis.3ds/*toutatis.cmod > vesta.3ds/*vesta.cmod > > * indicates use in the files of the data directory > > Do we actually need to keep all these unused meshes around? > > Regards, > Andrew > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers > |
From: Selden E B. Jr <se...@co...> - 2012-03-22 19:35:00
|
> I think it'd be a good idea to get rid of the Visual C++ .mak files. The > Visual C++ project file celestia.vcproj is still used by some people > though; I'd like to leave it there for now. I use it with Visual Studio Express 2008. It builds the current version of Celestia from SVN with no errors whatsoever. In contrast, I have never been able to get Celestia to build using Nokia's Qt Creator on that same Win7 x64 system using the SVN's .pro file. Both VS C++ and mingw options fail. FWIW, Cosmographia builds fine (albeit with warnings) on that same system using Qt Creator with mingw but fails with VSE. Selden > In the early days of Celestia, 3ds was the only supported model format. > When cmod was added, I converted all the meshes to the new format because > it loads faster (very little preprocessing required at load time for > cmods.) I left the 3ds versions around because 1) they're closer to the > original models, and 2) they can be easily viewed and edited in modeling > software, whereas cmod files cannot. It shouldn't be necessary to keep the > 3ds files around any more. It'd be better to just have a README file giving > the original sources of the shape models. Ideally, we'd also commit the > scripts required to convert models from their original formats to cmods. > --Chris > On Wed, Mar 21, 2012 at 12:28 PM, Andrew Tribick > <ajt...@go...>wrote: > > Hello, > > > > I've noticed that the src tree has several Visual C++ 6 > > projects/makefiles floating around, would anyone object if we got rid > > of these? > > > > There are also several duplicate models: > > > > amalthea.3ds/*amalthea.cmod > > bacchus.3ds/*bacchus.cmod > > castalia.3ds/*castalia.cmod > > deimos.3ds/*deimos.cmod > > epimetheus.3ds/*epimetheus.cmod > > eros.3ds/*eros.cmod/eros.cms > > gaspra.3ds/*gaspra.cmod > > geographos.3ds/*geographos.cmod > > golevka.3ds/*golevka.cmod > > halley.3ds/*halley.cmod > > hyperion.3ds/*hyperion.cmod/hyperion.cms > > ida.3ds/*ida.cmod > > janus.3ds/*janus.cmod > > kleopatra.3ds/*kleopatra.cmod > > ky26.3ds/*ky26.cmod > > larissa.3ds/*larissa.cmod > > pandora.3ds/*pandora.cmod > > phobos.3ds/*phobos.cmod > > phoebe.3ds/*phoebe.cmod > > prometheus.3ds/*prometheus.cmod > > proteus.3ds/*proteus.cmod/proteus.cms > > toutatis.3ds/*toutatis.cmod > > vesta.3ds/*vesta.cmod > > > > * indicates use in the files of the data directory > > > > Do we actually need to keep all these unused meshes around? > > > > Regards, > > Andrew > > > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > Celestia-developers mailing list > > Cel...@li... > > https://lists.sourceforge.net/lists/listinfo/celestia-developers > > |
From: Andrew T. <ajt...@go...> - 2012-03-22 19:13:51
|
> > In contrast, I have never been able to get Celestia to build using > Nokia's Qt Creator on that same Win7 x64 system using the SVN's .pro > file. Both VS C++ and mingw options fail. > Have you tried using the cmake files that I posted in the other thread? If you've installed Qt via the SDK there is the annoying issue that it doesn't add the Qt bin directory to the path by default, which is a bit inconvenient during the initial setup. My Windows system is also Win7 x64, though I am using VS2010 so I guess the updated Visual Studio DLLs I supplied may not work on your system because of the updated msvcrt.dll. CMake can also be used to generate Visual Studio solution files. I think ideally we should move to one build system for all platforms, so keeping the .sln files around is not ideal, though I will hold back on this for the moment. Andrew |
From: Fridger S. <fri...@de...> - 2012-03-22 22:19:37
|
Selden, On 03/22/2012 07:38 PM, Selden E Ball Jr wrote: > In contrast, I have never been able to get Celestia to build using > Nokia's Qt Creator on that same Win7 x64 system using the SVN's .pro > file. Both VS C++ and mingw options fail. This is really hard for me to understand. I also have a Win 7 64bit OS as well as a XP SP3 one. On the 32bit Win XP, I build with VS 2008 Express, and --since 1 year already -- I build Celestia.SVN with VS 2010 Express under Win 7 most regularly. For Win 7, I use as Tool Chain: "MS Windows SDK for Windows 7 (7.1.7600.0.30514)(x86)". MinGW is definitely "off limits" in all my installations for a number of reasons. On both systems I currently use Qt creator = 2.4.1 and Qt 4.8.0. Same on Linux, by the way. You did not describe what precisely your persistent Qt creator problems are. I am sure it must be a configuration issue, since I don't encounter any problems ( apart from obvious transient issues occasionally) . Of course, I also build Cosmographia almost daily with Qt creator, since Chris is working so hard there. Same setting, NO MinGW. According to my experience, most often, people fiddling with MinGW vs VS 20xx, forget adjusting the celestia.pro statement LIBS += /nodefaultlib:libcmt.lib and the service libs. Here is e.g. a respective summary. http://msdn.microsoft.com/en-us/library/aa267384%28v=vs.60%29.aspx In contrast, if you use a standard VS2010 Express and a current Qt, Qt-creator installation, Celestia should build out of the box (i.e. with the default celestia.pro). I suppose ChrisL works with the same tools, also without problems. For using VS 2008 you merely need to download binary Qt lib built with VS 2008 http://qt.nokia.com/downloads/windows-cpp-vs2008 For using VS2010 you need to download the binary Qt lib built with VS 2010 http://qt.nokia.com/downloads/windows-cpp-vs2010 It just takes a few minutes. Moreover you have to make sure of course that all the service libs were built within the proper system. It is best and straightforward to re-compile them for your system... Fridger > FWIW, Cosmographia builds fine (albeit with warnings) on that same system > using Qt Creator with mingw but fails with VSE. > > Selden > >> In the early days of Celestia, 3ds was the only supported model format. >> When cmod was added, I converted all the meshes to the new format because >> it loads faster (very little preprocessing required at load time for >> cmods.) I left the 3ds versions around because 1) they're closer to the >> original models, and 2) they can be easily viewed and edited in modeling >> software, whereas cmod files cannot. It shouldn't be necessary to keep the >> 3ds files around any more. It'd be better to just have a README file giving >> the original sources of the shape models. Ideally, we'd also commit the >> scripts required to convert models from their original formats to cmods. >> --Chris >> On Wed, Mar 21, 2012 at 12:28 PM, Andrew Tribick >> <ajt...@go...>wrote: >>> Hello, >>> >>> I've noticed that the src tree has several Visual C++ 6 >>> projects/makefiles floating around, would anyone object if we got rid >>> of these? >>> >>> There are also several duplicate models: >>> >>> amalthea.3ds/*amalthea.cmod >>> bacchus.3ds/*bacchus.cmod >>> castalia.3ds/*castalia.cmod >>> deimos.3ds/*deimos.cmod >>> epimetheus.3ds/*epimetheus.cmod >>> eros.3ds/*eros.cmod/eros.cms >>> gaspra.3ds/*gaspra.cmod >>> geographos.3ds/*geographos.cmod >>> golevka.3ds/*golevka.cmod >>> halley.3ds/*halley.cmod >>> hyperion.3ds/*hyperion.cmod/hyperion.cms >>> ida.3ds/*ida.cmod >>> janus.3ds/*janus.cmod >>> kleopatra.3ds/*kleopatra.cmod >>> ky26.3ds/*ky26.cmod >>> larissa.3ds/*larissa.cmod >>> pandora.3ds/*pandora.cmod >>> phobos.3ds/*phobos.cmod >>> phoebe.3ds/*phoebe.cmod >>> prometheus.3ds/*prometheus.cmod >>> proteus.3ds/*proteus.cmod/proteus.cms >>> toutatis.3ds/*toutatis.cmod >>> vesta.3ds/*vesta.cmod >>> >>> * indicates use in the files of the data directory >>> >>> Do we actually need to keep all these unused meshes around? >>> >>> Regards, >>> Andrew >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF email is sponsosred by: >>> Try Windows Azure free for 90 days Click Here >>> http://p.sf.net/sfu/sfd2d-msazure >>> _______________________________________________ >>> Celestia-developers mailing list >>> Cel...@li... >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>> > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Selden E B. Jr <se...@co...> - 2012-03-22 23:00:59
|
Fridger, As I mentioned, I'm using Qt-Creator (it's v2.2.0). As best I can tell, the Web page http://qt.nokia.com/downloads/windows-cpp-vs2008 provides a download of a Qt development environment, not just the necessary VS libraries. My jnderstanding is that QtCreator already includes that development environment. I'm hesitant to install the Qt environment in case it would trash the QtCreator environment. The errors I get when using QtCreator to build Celestia do seem to be related to missing (or unsearched) libraries: unresolved external symbol _libintl_sprintf (in many routines) unresolved external symbol _png_set_longmp_fn unresolved external symbol _libintl_setlocale Those are the only unresolved symbols that it complains about, though. s. > Selden, > On 03/22/2012 07:38 PM, Selden E Ball Jr wrote: > > In contrast, I have never been able to get Celestia to build using > > Nokia's Qt Creator on that same Win7 x64 system using the SVN's .pro > > file. Both VS C++ and mingw options fail. > This is really hard for me to understand. I also have a Win 7 64bit OS > as well as a XP SP3 one. On the 32bit Win XP, I build with VS 2008 > Express, and --since 1 year already -- I build Celestia.SVN with VS > 2010 Express under Win 7 most regularly. For Win 7, I use as Tool Chain: > "MS Windows SDK for Windows 7 (7.1.7600.0.30514)(x86)". > MinGW is definitely "off limits" in all my installations for a number of > reasons. > On both systems I currently use Qt creator = 2.4.1 and Qt 4.8.0. Same on > Linux, by the way. > You did not describe what precisely your persistent Qt creator problems > are. I am sure it must be a configuration issue, since I don't > encounter any problems ( apart from obvious transient issues > occasionally) . Of course, I also build Cosmographia almost daily with > Qt creator, since Chris is working so hard there. Same setting, NO MinGW. > According to my experience, most often, people fiddling with MinGW vs VS > 20xx, forget adjusting the celestia.pro statement > LIBS += /nodefaultlib:libcmt.lib > and the service libs. > Here is e.g. a respective summary. > http://msdn.microsoft.com/en-us/library/aa267384%28v=vs.60%29.aspx > In contrast, if you use a standard VS2010 Express and a current Qt, > Qt-creator installation, Celestia should build out of the box (i.e. with > the default celestia.pro). I suppose ChrisL works with the same tools, > also without problems. > For using VS 2008 you merely need to download binary Qt lib built with > VS 2008 > http://qt.nokia.com/downloads/windows-cpp-vs2008 > For using VS2010 you need to download the binary Qt lib built with VS 2010 > http://qt.nokia.com/downloads/windows-cpp-vs2010 > It just takes a few minutes. > Moreover you have to make sure of course that all the service libs were > built within the proper system. It is best and straightforward to > re-compile them for your system... > Fridger > > FWIW, Cosmographia builds fine (albeit with warnings) on that same system > > using Qt Creator with mingw but fails with VSE. > > > > Selden > > > >> In the early days of Celestia, 3ds was the only supported model format. > >> When cmod was added, I converted all the meshes to the new format because > >> it loads faster (very little preprocessing required at load time for > >> cmods.) I left the 3ds versions around because 1) they're closer to the > >> original models, and 2) they can be easily viewed and edited in modeling > >> software, whereas cmod files cannot. It shouldn't be necessary to keep the > >> 3ds files around any more. It'd be better to just have a README file giving > >> the original sources of the shape models. Ideally, we'd also commit the > >> scripts required to convert models from their original formats to cmods. > >> --Chris > >> On Wed, Mar 21, 2012 at 12:28 PM, Andrew Tribick > >> <ajt...@go...>wrote: > >>> Hello, > >>> > >>> I've noticed that the src tree has several Visual C++ 6 > >>> projects/makefiles floating around, would anyone object if we got rid > >>> of these? > >>> > >>> There are also several duplicate models: > >>> > >>> amalthea.3ds/*amalthea.cmod > >>> bacchus.3ds/*bacchus.cmod > >>> castalia.3ds/*castalia.cmod > >>> deimos.3ds/*deimos.cmod > >>> epimetheus.3ds/*epimetheus.cmod > >>> eros.3ds/*eros.cmod/eros.cms > >>> gaspra.3ds/*gaspra.cmod > >>> geographos.3ds/*geographos.cmod > >>> golevka.3ds/*golevka.cmod > >>> halley.3ds/*halley.cmod > >>> hyperion.3ds/*hyperion.cmod/hyperion.cms > >>> ida.3ds/*ida.cmod > >>> janus.3ds/*janus.cmod > >>> kleopatra.3ds/*kleopatra.cmod > >>> ky26.3ds/*ky26.cmod > >>> larissa.3ds/*larissa.cmod > >>> pandora.3ds/*pandora.cmod > >>> phobos.3ds/*phobos.cmod > >>> phoebe.3ds/*phoebe.cmod > >>> prometheus.3ds/*prometheus.cmod > >>> proteus.3ds/*proteus.cmod/proteus.cms > >>> toutatis.3ds/*toutatis.cmod > >>> vesta.3ds/*vesta.cmod > >>> > >>> * indicates use in the files of the data directory > >>> > >>> Do we actually need to keep all these unused meshes around? > >>> > >>> Regards, > >>> Andrew > >>> > >>> > >>> ------------------------------------------------------------------------------ > >>> This SF email is sponsosred by: > >>> Try Windows Azure free for 90 days Click Here > >>> http://p.sf.net/sfu/sfd2d-msazure > >>> _______________________________________________ > >>> Celestia-developers mailing list > >>> Cel...@li... > >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers > >>> > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > Celestia-developers mailing list > > Cel...@li... > > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Fridger S. <fri...@de...> - 2012-03-22 23:22:17
|
Selden. On 03/22/2012 11:52 PM, Selden E Ball Jr wrote: > Fridger, > > As I mentioned, I'm using Qt-Creator (it's v2.2.0). > As best I can tell, the Web page > http://qt.nokia.com/downloads/windows-cpp-vs2008 > provides a download of a Qt development environment, not just the > necessary VS libraries. My jnderstanding is that QtCreator already > includes that development environment. I'm hesitant to install > the Qt environment in case it would trash the QtCreator environment. > I can assure you that you will trash nothing, if you do a complete installation of the VS 2010 Express compiler (that will also provide the required tool chain for Qt creator), the matching /binary/ lib download (see link in previous mail) and the separate /binary/ Qt-creator 2.4.1 from http://qt.nokia.com/downloads/qt-creator-binary-for-windows That's all you need and the total installation takes less than 15 min. During installation un-tick the MinGW option. Installing the Qt SDK takes much longer and redoubles part of the installation if you got a complete resident VS 2010 Express. I am doing this procedure now since several years both on my Windows and my Linux machines, and it has always worked for me. As to a deinstallation of VS 2008 Express, there is ample info on the net. There are rare cases where some parts don't deinstall straightforwardly. Then the proper procedure is given at MS. > The errors I get when using QtCreator to build Celestia do seem to be > related to missing (or unsearched) libraries: > > unresolved external symbol _libintl_sprintf (in many routines) > unresolved external symbol _png_set_longmp_fn > unresolved external symbol _libintl_setlocale > I suppose you did not forget to copy the respective .dll's from windows/dll/x86 into celestia's root dir? > Those are the only unresolved symbols that it complains about, though. > > s. > > >> Selden, > >> On 03/22/2012 07:38 PM, Selden E Ball Jr wrote: >> > In contrast, I have never been able to get Celestia to build using >> > Nokia's Qt Creator on that same Win7 x64 system using the SVN's .pro >> > file. Both VS C++ and mingw options fail. >> This is really hard for me to understand. I also have a Win 7 64bit OS >> as well as a XP SP3 one. On the 32bit Win XP, I build with VS 2008 >> Express, and --since 1 year already -- I build Celestia.SVN with VS >> 2010 Express under Win 7 most regularly. For Win 7, I use as Tool Chain: >> "MS Windows SDK for Windows 7 (7.1.7600.0.30514)(x86)". > >> MinGW is definitely "off limits" in all my installations for a number of >> reasons. >> On both systems I currently use Qt creator = 2.4.1 and Qt 4.8.0. Same on >> Linux, by the way. > >> You did not describe what precisely your persistent Qt creator problems >> are. I am sure it must be a configuration issue, since I don't >> encounter any problems ( apart from obvious transient issues >> occasionally) . Of course, I also build Cosmographia almost daily with >> Qt creator, since Chris is working so hard there. Same setting, NO >> MinGW. > >> According to my experience, most often, people fiddling with MinGW vs VS >> 20xx, forget adjusting the celestia.pro statement > >> LIBS += /nodefaultlib:libcmt.lib > >> and the service libs. > >> Here is e.g. a respective summary. >> http://msdn.microsoft.com/en-us/library/aa267384%28v=vs.60%29.aspx > >> In contrast, if you use a standard VS2010 Express and a current Qt, >> Qt-creator installation, Celestia should build out of the box (i.e. with >> the default celestia.pro). I suppose ChrisL works with the same tools, >> also without problems. > >> For using VS 2008 you merely need to download binary Qt lib built with >> VS 2008 >> http://qt.nokia.com/downloads/windows-cpp-vs2008 >> For using VS2010 you need to download the binary Qt lib built with VS >> 2010 >> http://qt.nokia.com/downloads/windows-cpp-vs2010 > >> It just takes a few minutes. > >> Moreover you have to make sure of course that all the service libs were >> built within the proper system. It is best and straightforward to >> re-compile them for your system... > >> Fridger >> > FWIW, Cosmographia builds fine (albeit with warnings) on that same >> system >> > using Qt Creator with mingw but fails with VSE. >> > >> > Selden >> > >> >> In the early days of Celestia, 3ds was the only supported model >> format. >> >> When cmod was added, I converted all the meshes to the new format >> because >> >> it loads faster (very little preprocessing required at load time for >> >> cmods.) I left the 3ds versions around because 1) they're closer >> to the >> >> original models, and 2) they can be easily viewed and edited in >> modeling >> >> software, whereas cmod files cannot. It shouldn't be necessary to >> keep the >> >> 3ds files around any more. It'd be better to just have a README >> file giving >> >> the original sources of the shape models. Ideally, we'd also >> commit the >> >> scripts required to convert models from their original formats to >> cmods. >> >> --Chris >> >> On Wed, Mar 21, 2012 at 12:28 PM, Andrew Tribick >> >> <ajt...@go...>wrote: >> >>> Hello, >> >>> >> >>> I've noticed that the src tree has several Visual C++ 6 >> >>> projects/makefiles floating around, would anyone object if we got >> rid >> >>> of these? >> >>> >> >>> There are also several duplicate models: >> >>> >> >>> amalthea.3ds/*amalthea.cmod >> >>> bacchus.3ds/*bacchus.cmod >> >>> castalia.3ds/*castalia.cmod >> >>> deimos.3ds/*deimos.cmod >> >>> epimetheus.3ds/*epimetheus.cmod >> >>> eros.3ds/*eros.cmod/eros.cms >> >>> gaspra.3ds/*gaspra.cmod >> >>> geographos.3ds/*geographos.cmod >> >>> golevka.3ds/*golevka.cmod >> >>> halley.3ds/*halley.cmod >> >>> hyperion.3ds/*hyperion.cmod/hyperion.cms >> >>> ida.3ds/*ida.cmod >> >>> janus.3ds/*janus.cmod >> >>> kleopatra.3ds/*kleopatra.cmod >> >>> ky26.3ds/*ky26.cmod >> >>> larissa.3ds/*larissa.cmod >> >>> pandora.3ds/*pandora.cmod >> >>> phobos.3ds/*phobos.cmod >> >>> phoebe.3ds/*phoebe.cmod >> >>> prometheus.3ds/*prometheus.cmod >> >>> proteus.3ds/*proteus.cmod/proteus.cms >> >>> toutatis.3ds/*toutatis.cmod >> >>> vesta.3ds/*vesta.cmod >> >>> >> >>> * indicates use in the files of the data directory >> >>> >> >>> Do we actually need to keep all these unused meshes around? >> >>> >> >>> Regards, >> >>> Andrew >> >>> >> >>> >> >>> >> ------------------------------------------------------------------------------ >> >>> This SF email is sponsosred by: >> >>> Try Windows Azure free for 90 days Click Here >> >>> http://p.sf.net/sfu/sfd2d-msazure >> >>> _______________________________________________ >> >>> Celestia-developers mailing list >> >>> Cel...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >> >>> >> > >> ------------------------------------------------------------------------------ >> > This SF email is sponsosred by: >> > Try Windows Azure free for 90 days Click Here >> > http://p.sf.net/sfu/sfd2d-msazure >> > _______________________________________________ >> > Celestia-developers mailing list >> > Cel...@li... >> > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Selden E B. Jr <se...@co...> - 2012-03-23 00:01:54
|
Fridger, Since the VS2008 Express environment builds the non-Qt version of Celestia with no problems at all, I am very relctant to spend the time necessary to set up the environment which is needed to build Celestia under VS2010. You probably did that a long time ago and have fogotten the annoyances involved. A brief description of some of the necessary steps, including getting and building zlib and png libraries (except for their unknown dependencies) from SourceForge, is in the WikiBook at http://en.wikibooks.org/wiki/Celestia/Development/Win32_platform#VS2010 The Windows Celestia dlls that I currently have are iconv.dll intl.dll libiconv-2.dll libintl-8.dll lua5.1.dll and lua51.dll. I just now copied them (again) to the Celestia directory and rebuilt Qt Celestia. QtCreator still complains about the same three missing external symbols: > > unresolved external symbol _libintl_sprintf (in many routines) > > unresolved external symbol _png_set_longmp_fn > > unresolved external symbol _libintl_setlocale It is not at all obvious to me where I could find whatever libraries are needed to provide the missing routines referenced by the Qt build. If they are provided by rebuilding some of the libraries currently provided by the svn, then it seems to me that those rebuilt libraries should be provided in the svn repository. If VS2010 is required in order to build those modified libraries, then I believe that the svn repository should be updated to support building with VS2010 instead of VS2008. s. > Selden. > On 03/22/2012 11:52 PM, Selden E Ball Jr wrote: > > Fridger, > > > > As I mentioned, I'm using Qt-Creator (it's v2.2.0). > > As best I can tell, the Web page > > http://qt.nokia.com/downloads/windows-cpp-vs2008 > > provides a download of a Qt development environment, not just the > > necessary VS libraries. My jnderstanding is that QtCreator already > > includes that development environment. I'm hesitant to install > > the Qt environment in case it would trash the QtCreator environment. > > > I can assure you that you will trash nothing, if you do a complete > installation of the VS 2010 Express compiler (that will also provide the > required tool chain for Qt creator), the matching /binary/ lib download > (see link in previous mail) and the separate /binary/ Qt-creator 2.4.1 from > http://qt.nokia.com/downloads/qt-creator-binary-for-windows > That's all you need and the total installation takes less than 15 min. > During installation un-tick the MinGW option. Installing the Qt SDK > takes much longer and redoubles part of the installation if you got a > complete resident VS 2010 Express. I am doing this procedure now since > several years both on my Windows and my Linux machines, and it has > always worked for me. > As to a deinstallation of VS 2008 Express, there is ample info on the > net. There are rare cases where some parts don't deinstall > straightforwardly. Then the proper procedure is given at MS. > > The errors I get when using QtCreator to build Celestia do seem to be > > related to missing (or unsearched) libraries: > > > > unresolved external symbol _libintl_sprintf (in many routines) > > unresolved external symbol _png_set_longmp_fn > > unresolved external symbol _libintl_setlocale > > > I suppose you did not forget to copy the respective .dll's from > windows/dll/x86 into celestia's root dir? > > Those are the only unresolved symbols that it complains about, though. > > > > s. > > > > > >> Selden, > > > >> On 03/22/2012 07:38 PM, Selden E Ball Jr wrote: > >> > In contrast, I have never been able to get Celestia to build using > >> > Nokia's Qt Creator on that same Win7 x64 system using the SVN's .pro > >> > file. Both VS C++ and mingw options fail. > >> This is really hard for me to understand. I also have a Win 7 64bit OS > >> as well as a XP SP3 one. On the 32bit Win XP, I build with VS 2008 > >> Express, and --since 1 year already -- I build Celestia.SVN with VS > >> 2010 Express under Win 7 most regularly. For Win 7, I use as Tool Chain: > >> "MS Windows SDK for Windows 7 (7.1.7600.0.30514)(x86)". > > > >> MinGW is definitely "off limits" in all my installations for a number of > >> reasons. > >> On both systems I currently use Qt creator = 2.4.1 and Qt 4.8.0. Same on > >> Linux, by the way. > > > >> You did not describe what precisely your persistent Qt creator problems > >> are. I am sure it must be a configuration issue, since I don't > >> encounter any problems ( apart from obvious transient issues > >> occasionally) . Of course, I also build Cosmographia almost daily with > >> Qt creator, since Chris is working so hard there. Same setting, NO > >> MinGW. > > > >> According to my experience, most often, people fiddling with MinGW vs VS > >> 20xx, forget adjusting the celestia.pro statement > > > >> LIBS += /nodefaultlib:libcmt.lib > > > >> and the service libs. > > > >> Here is e.g. a respective summary. > >> http://msdn.microsoft.com/en-us/library/aa267384%28v=vs.60%29.aspx > > > >> In contrast, if you use a standard VS2010 Express and a current Qt, > >> Qt-creator installation, Celestia should build out of the box (i.e. with > >> the default celestia.pro). I suppose ChrisL works with the same tools, > >> also without problems. > > > >> For using VS 2008 you merely need to download binary Qt lib built with > >> VS 2008 > >> http://qt.nokia.com/downloads/windows-cpp-vs2008 > >> For using VS2010 you need to download the binary Qt lib built with VS > >> 2010 > >> http://qt.nokia.com/downloads/windows-cpp-vs2010 > > > >> It just takes a few minutes. > > > >> Moreover you have to make sure of course that all the service libs were > >> built within the proper system. It is best and straightforward to > >> re-compile them for your system... > > > >> Fridger > >> > FWIW, Cosmographia builds fine (albeit with warnings) on that same > >> system > >> > using Qt Creator with mingw but fails with VSE. > >> > > >> > Selden > >> > > >> >> In the early days of Celestia, 3ds was the only supported model > >> format. > >> >> When cmod was added, I converted all the meshes to the new format > >> because > >> >> it loads faster (very little preprocessing required at load time for > >> >> cmods.) I left the 3ds versions around because 1) they're closer > >> to the > >> >> original models, and 2) they can be easily viewed and edited in > >> modeling > >> >> software, whereas cmod files cannot. It shouldn't be necessary to > >> keep the > >> >> 3ds files around any more. It'd be better to just have a README > >> file giving > >> >> the original sources of the shape models. Ideally, we'd also > >> commit the > >> >> scripts required to convert models from their original formats to > >> cmods. > >> >> --Chris > >> >> On Wed, Mar 21, 2012 at 12:28 PM, Andrew Tribick > >> >> <ajt...@go...>wrote: > >> >>> Hello, > >> >>> > >> >>> I've noticed that the src tree has several Visual C++ 6 > >> >>> projects/makefiles floating around, would anyone object if we got > >> rid > >> >>> of these? > >> >>> > >> >>> There are also several duplicate models: > >> >>> > >> >>> amalthea.3ds/*amalthea.cmod > >> >>> bacchus.3ds/*bacchus.cmod > >> >>> castalia.3ds/*castalia.cmod > >> >>> deimos.3ds/*deimos.cmod > >> >>> epimetheus.3ds/*epimetheus.cmod > >> >>> eros.3ds/*eros.cmod/eros.cms > >> >>> gaspra.3ds/*gaspra.cmod > >> >>> geographos.3ds/*geographos.cmod > >> >>> golevka.3ds/*golevka.cmod > >> >>> halley.3ds/*halley.cmod > >> >>> hyperion.3ds/*hyperion.cmod/hyperion.cms > >> >>> ida.3ds/*ida.cmod > >> >>> janus.3ds/*janus.cmod > >> >>> kleopatra.3ds/*kleopatra.cmod > >> >>> ky26.3ds/*ky26.cmod > >> >>> larissa.3ds/*larissa.cmod > >> >>> pandora.3ds/*pandora.cmod > >> >>> phobos.3ds/*phobos.cmod > >> >>> phoebe.3ds/*phoebe.cmod > >> >>> prometheus.3ds/*prometheus.cmod > >> >>> proteus.3ds/*proteus.cmod/proteus.cms > >> >>> toutatis.3ds/*toutatis.cmod > >> >>> vesta.3ds/*vesta.cmod > >> >>> > >> >>> * indicates use in the files of the data directory > >> >>> > >> >>> Do we actually need to keep all these unused meshes around? > >> >>> > >> >>> Regards, > >> >>> Andrew > >> >>> > >> >>> > >> >>> > >> ------------------------------------------------------------------------------ > >> >>> This SF email is sponsosred by: > >> >>> Try Windows Azure free for 90 days Click Here > >> >>> http://p.sf.net/sfu/sfd2d-msazure > >> >>> _______________________________________________ > >> >>> Celestia-developers mailing list > >> >>> Cel...@li... > >> >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers > >> >>> > >> > > >> ------------------------------------------------------------------------------ > >> > This SF email is sponsosred by: > >> > Try Windows Azure free for 90 days Click Here > >> > http://p.sf.net/sfu/sfd2d-msazure > >> > _______________________________________________ > >> > Celestia-developers mailing list > >> > Cel...@li... > >> > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: PR@Celestia <pr-...@ar...> - 2012-03-24 09:30:14
|
Dear all, I think it would be a great idea if someone would be going ahead and write a chapter in the Celestia Wikibook about what is needed to get a clean installation of Qt under the different operating systems and compilers to run. Especially Linux would probably be beneficial for some (myself included). Like Fridger here wrote, which Binary to download and which one not and so on. I am also having troubles sometimes when I update the Qt Versions because I forget to upgrade the installation path to the Qt binary. But if it finally runs, it builds okay (XP3). Best regards, Christian Am 23.03.2012 00:23, schrieb Selden E Ball Jr: > Fridger, > > Since the VS2008 Express environment builds the non-Qt version of Celestia > with no problems at all, I am very relctant to spend the time necessary > to set up the environment which is needed to build Celestia under VS2010. > You probably did that a long time ago and have fogotten the annoyances > involved. > > A brief description of some of the necessary steps, including getting > and building zlib and png libraries (except for their unknown dependencies) > from SourceForge, is in the WikiBook at > http://en.wikibooks.org/wiki/Celestia/Development/Win32_platform#VS2010 > > The Windows Celestia dlls that I currently have are > iconv.dll intl.dll libiconv-2.dll libintl-8.dll lua5.1.dll and > lua51.dll. I just now copied them (again) to the Celestia directory > and rebuilt Qt Celestia. QtCreator still complains about the same three > missing external symbols: > >>> unresolved external symbol _libintl_sprintf (in many routines) >>> unresolved external symbol _png_set_longmp_fn >>> unresolved external symbol _libintl_setlocale > > It is not at all obvious to me where I could find whatever > libraries are needed to provide the missing routines referenced > by the Qt build. > > If they are provided by rebuilding some of the libraries currently > provided by the svn, then it seems to me that those rebuilt libraries > should be provided in the svn repository. If VS2010 is required > in order to build those modified libraries, then I believe that the svn > repository should be updated to support building with VS2010 > instead of VS2008. > > s. > >> Selden. > >> On 03/22/2012 11:52 PM, Selden E Ball Jr wrote: >>> Fridger, >>> >>> As I mentioned, I'm using Qt-Creator (it's v2.2.0). >>> As best I can tell, the Web page >>> http://qt.nokia.com/downloads/windows-cpp-vs2008 >>> provides a download of a Qt development environment, not just the >>> necessary VS libraries. My jnderstanding is that QtCreator already >>> includes that development environment. I'm hesitant to install >>> the Qt environment in case it would trash the QtCreator environment. >>> >> I can assure you that you will trash nothing, if you do a complete >> installation of the VS 2010 Express compiler (that will also provide the >> required tool chain for Qt creator), the matching /binary/ lib download >> (see link in previous mail) and the separate /binary/ Qt-creator 2.4.1 from >> http://qt.nokia.com/downloads/qt-creator-binary-for-windows > >> That's all you need and the total installation takes less than 15 min. >> During installation un-tick the MinGW option. Installing the Qt SDK >> takes much longer and redoubles part of the installation if you got a >> complete resident VS 2010 Express. I am doing this procedure now since >> several years both on my Windows and my Linux machines, and it has >> always worked for me. > >> As to a deinstallation of VS 2008 Express, there is ample info on the >> net. There are rare cases where some parts don't deinstall >> straightforwardly. Then the proper procedure is given at MS. > >>> The errors I get when using QtCreator to build Celestia do seem to be >>> related to missing (or unsearched) libraries: >>> >>> unresolved external symbol _libintl_sprintf (in many routines) >>> unresolved external symbol _png_set_longmp_fn >>> unresolved external symbol _libintl_setlocale >>> > >> I suppose you did not forget to copy the respective .dll's from >> windows/dll/x86 into celestia's root dir? > >>> Those are the only unresolved symbols that it complains about, though. >>> >>> s. >>> >>> >>>> Selden, >>> >>>> On 03/22/2012 07:38 PM, Selden E Ball Jr wrote: >>>>> In contrast, I have never been able to get Celestia to build using >>>>> Nokia's Qt Creator on that same Win7 x64 system using the SVN's .pro >>>>> file. Both VS C++ and mingw options fail. >>>> This is really hard for me to understand. I also have a Win 7 64bit OS >>>> as well as a XP SP3 one. On the 32bit Win XP, I build with VS 2008 >>>> Express, and --since 1 year already -- I build Celestia.SVN with VS >>>> 2010 Express under Win 7 most regularly. For Win 7, I use as Tool Chain: >>>> "MS Windows SDK for Windows 7 (7.1.7600.0.30514)(x86)". >>> >>>> MinGW is definitely "off limits" in all my installations for a number of >>>> reasons. >>>> On both systems I currently use Qt creator = 2.4.1 and Qt 4.8.0. Same on >>>> Linux, by the way. >>> >>>> You did not describe what precisely your persistent Qt creator problems >>>> are. I am sure it must be a configuration issue, since I don't >>>> encounter any problems ( apart from obvious transient issues >>>> occasionally) . Of course, I also build Cosmographia almost daily with >>>> Qt creator, since Chris is working so hard there. Same setting, NO >>>> MinGW. >>> >>>> According to my experience, most often, people fiddling with MinGW vs VS >>>> 20xx, forget adjusting the celestia.pro statement >>> >>>> LIBS += /nodefaultlib:libcmt.lib >>> >>>> and the service libs. >>> >>>> Here is e.g. a respective summary. >>>> http://msdn.microsoft.com/en-us/library/aa267384%28v=vs.60%29.aspx >>> >>>> In contrast, if you use a standard VS2010 Express and a current Qt, >>>> Qt-creator installation, Celestia should build out of the box (i.e. with >>>> the default celestia.pro). I suppose ChrisL works with the same tools, >>>> also without problems. >>> >>>> For using VS 2008 you merely need to download binary Qt lib built with >>>> VS 2008 >>>> http://qt.nokia.com/downloads/windows-cpp-vs2008 >>>> For using VS2010 you need to download the binary Qt lib built with VS >>>> 2010 >>>> http://qt.nokia.com/downloads/windows-cpp-vs2010 >>> >>>> It just takes a few minutes. >>> >>>> Moreover you have to make sure of course that all the service libs were >>>> built within the proper system. It is best and straightforward to >>>> re-compile them for your system... >>> >>>> Fridger >>>>> FWIW, Cosmographia builds fine (albeit with warnings) on that same >>>> system >>>>> using Qt Creator with mingw but fails with VSE. >>>>> >>>>> Selden >>>>> >>>>>> In the early days of Celestia, 3ds was the only supported model >>>> format. >>>>>> When cmod was added, I converted all the meshes to the new format >>>> because >>>>>> it loads faster (very little preprocessing required at load time for >>>>>> cmods.) I left the 3ds versions around because 1) they're closer >>>> to the >>>>>> original models, and 2) they can be easily viewed and edited in >>>> modeling >>>>>> software, whereas cmod files cannot. It shouldn't be necessary to >>>> keep the >>>>>> 3ds files around any more. It'd be better to just have a README >>>> file giving >>>>>> the original sources of the shape models. Ideally, we'd also >>>> commit the >>>>>> scripts required to convert models from their original formats to >>>> cmods. >>>>>> --Chris >>>>>> On Wed, Mar 21, 2012 at 12:28 PM, Andrew Tribick >>>>>> <ajt...@go...>wrote: >>>>>>> Hello, >>>>>>> >>>>>>> I've noticed that the src tree has several Visual C++ 6 >>>>>>> projects/makefiles floating around, would anyone object if we got >>>> rid >>>>>>> of these? >>>>>>> >>>>>>> There are also several duplicate models: >>>>>>> >>>>>>> amalthea.3ds/*amalthea.cmod >>>>>>> bacchus.3ds/*bacchus.cmod >>>>>>> castalia.3ds/*castalia.cmod >>>>>>> deimos.3ds/*deimos.cmod >>>>>>> epimetheus.3ds/*epimetheus.cmod >>>>>>> eros.3ds/*eros.cmod/eros.cms >>>>>>> gaspra.3ds/*gaspra.cmod >>>>>>> geographos.3ds/*geographos.cmod >>>>>>> golevka.3ds/*golevka.cmod >>>>>>> halley.3ds/*halley.cmod >>>>>>> hyperion.3ds/*hyperion.cmod/hyperion.cms >>>>>>> ida.3ds/*ida.cmod >>>>>>> janus.3ds/*janus.cmod >>>>>>> kleopatra.3ds/*kleopatra.cmod >>>>>>> ky26.3ds/*ky26.cmod >>>>>>> larissa.3ds/*larissa.cmod >>>>>>> pandora.3ds/*pandora.cmod >>>>>>> phobos.3ds/*phobos.cmod >>>>>>> phoebe.3ds/*phoebe.cmod >>>>>>> prometheus.3ds/*prometheus.cmod >>>>>>> proteus.3ds/*proteus.cmod/proteus.cms >>>>>>> toutatis.3ds/*toutatis.cmod >>>>>>> vesta.3ds/*vesta.cmod >>>>>>> >>>>>>> * indicates use in the files of the data directory >>>>>>> >>>>>>> Do we actually need to keep all these unused meshes around? >>>>>>> >>>>>>> Regards, >>>>>>> Andrew >>>>>>> >>>>>>> >>>>>>> >>>> ------------------------------------------------------------------------------ >>>>>>> This SF email is sponsosred by: >>>>>>> Try Windows Azure free for 90 days Click Here >>>>>>> http://p.sf.net/sfu/sfd2d-msazure >>>>>>> _______________________________________________ >>>>>>> Celestia-developers mailing list >>>>>>> Cel...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>>> This SF email is sponsosred by: >>>>> Try Windows Azure free for 90 days Click Here >>>>> http://p.sf.net/sfu/sfd2d-msazure >>>>> _______________________________________________ >>>>> Celestia-developers mailing list >>>>> Cel...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Selden E B. Jr <se...@co...> - 2012-03-24 15:31:22
|
I finally managed to get Celestia to build and run with the Qt interface by updating to the most recent version of the Qt IDE. It was a quite frustrating procedure since it took so long (more than 3 hours) and I had to restart it several times last night and this morning. I've started an initial description of the Qt build procedure at http://en.wikibooks.org/wiki/Celestia/Development/Qt4#Building_Celestia I've written some rudimentary instructions for Windows, but it needs filling out. Someone else will have to write the Linux and MacOS instructions. Selden > Dear all, > I think it would be a great idea if someone would be going ahead and > write a chapter in the Celestia Wikibook about what is needed to get a > clean installation of Qt under the different operating systems and > compilers to run. Especially Linux would probably be beneficial for some > (myself included). > Like Fridger here wrote, which Binary to download and which one not and > so on. I am also having troubles sometimes when I update the Qt Versions > because I forget to upgrade the installation path to the Qt binary. > But if it finally runs, it builds okay (XP3). > Best regards, > Christian > Am 23.03.2012 00:23, schrieb Selden E Ball Jr: > > Fridger, > > > > Since the VS2008 Express environment builds the non-Qt version of Celestia > > with no problems at all, I am very relctant to spend the time necessary > > to set up the environment which is needed to build Celestia under VS2010. > > You probably did that a long time ago and have fogotten the annoyances > > involved. > > > > A brief description of some of the necessary steps, including getting > > and building zlib and png libraries (except for their unknown dependencies) > > from SourceForge, is in the WikiBook at > > http://en.wikibooks.org/wiki/Celestia/Development/Win32_platform#VS2010 > > > > The Windows Celestia dlls that I currently have are > > iconv.dll intl.dll libiconv-2.dll libintl-8.dll lua5.1.dll and > > lua51.dll. I just now copied them (again) to the Celestia directory > > and rebuilt Qt Celestia. QtCreator still complains about the same three > > missing external symbols: > > > >>> unresolved external symbol _libintl_sprintf (in many routines) > >>> unresolved external symbol _png_set_longmp_fn > >>> unresolved external symbol _libintl_setlocale > > > > It is not at all obvious to me where I could find whatever > > libraries are needed to provide the missing routines referenced > > by the Qt build. > > > > If they are provided by rebuilding some of the libraries currently > > provided by the svn, then it seems to me that those rebuilt libraries > > should be provided in the svn repository. If VS2010 is required > > in order to build those modified libraries, then I believe that the svn > > repository should be updated to support building with VS2010 > > instead of VS2008. > > > > s. > > > >> Selden. > > > >> On 03/22/2012 11:52 PM, Selden E Ball Jr wrote: > >>> Fridger, > >>> > >>> As I mentioned, I'm using Qt-Creator (it's v2.2.0). > >>> As best I can tell, the Web page > >>> http://qt.nokia.com/downloads/windows-cpp-vs2008 > >>> provides a download of a Qt development environment, not just the > >>> necessary VS libraries. My jnderstanding is that QtCreator already > >>> includes that development environment. I'm hesitant to install > >>> the Qt environment in case it would trash the QtCreator environment. > >>> > >> I can assure you that you will trash nothing, if you do a complete > >> installation of the VS 2010 Express compiler (that will also provide the > >> required tool chain for Qt creator), the matching /binary/ lib download > >> (see link in previous mail) and the separate /binary/ Qt-creator 2.4.1 from > >> http://qt.nokia.com/downloads/qt-creator-binary-for-windows > > > >> That's all you need and the total installation takes less than 15 min. > >> During installation un-tick the MinGW option. Installing the Qt SDK > >> takes much longer and redoubles part of the installation if you got a > >> complete resident VS 2010 Express. I am doing this procedure now since > >> several years both on my Windows and my Linux machines, and it has > >> always worked for me. > > > >> As to a deinstallation of VS 2008 Express, there is ample info on the > >> net. There are rare cases where some parts don't deinstall > >> straightforwardly. Then the proper procedure is given at MS. > > > >>> The errors I get when using QtCreator to build Celestia do seem to be > >>> related to missing (or unsearched) libraries: > >>> > >>> unresolved external symbol _libintl_sprintf (in many routines) > >>> unresolved external symbol _png_set_longmp_fn > >>> unresolved external symbol _libintl_setlocale > >>> > > > >> I suppose you did not forget to copy the respective .dll's from > >> windows/dll/x86 into celestia's root dir? > > > >>> Those are the only unresolved symbols that it complains about, though. > >>> > >>> s. > >>> > >>> > >>>> Selden, > >>> > >>>> On 03/22/2012 07:38 PM, Selden E Ball Jr wrote: > >>>>> In contrast, I have never been able to get Celestia to build using > >>>>> Nokia's Qt Creator on that same Win7 x64 system using the SVN's .pro > >>>>> file. Both VS C++ and mingw options fail. > >>>> This is really hard for me to understand. I also have a Win 7 64bit OS > >>>> as well as a XP SP3 one. On the 32bit Win XP, I build with VS 2008 > >>>> Express, and --since 1 year already -- I build Celestia.SVN with VS > >>>> 2010 Express under Win 7 most regularly. For Win 7, I use as Tool Chain: > >>>> "MS Windows SDK for Windows 7 (7.1.7600.0.30514)(x86)". > >>> > >>>> MinGW is definitely "off limits" in all my installations for a number of > >>>> reasons. > >>>> On both systems I currently use Qt creator = 2.4.1 and Qt 4.8.0. Same on > >>>> Linux, by the way. > >>> > >>>> You did not describe what precisely your persistent Qt creator problems > >>>> are. I am sure it must be a configuration issue, since I don't > >>>> encounter any problems ( apart from obvious transient issues > >>>> occasionally) . Of course, I also build Cosmographia almost daily with > >>>> Qt creator, since Chris is working so hard there. Same setting, NO > >>>> MinGW. > >>> > >>>> According to my experience, most often, people fiddling with MinGW vs VS > >>>> 20xx, forget adjusting the celestia.pro statement > >>> > >>>> LIBS += /nodefaultlib:libcmt.lib > >>> > >>>> and the service libs. > >>> > >>>> Here is e.g. a respective summary. > >>>> http://msdn.microsoft.com/en-us/library/aa267384%28v=vs.60%29.aspx > >>> > >>>> In contrast, if you use a standard VS2010 Express and a current Qt, > >>>> Qt-creator installation, Celestia should build out of the box (i.e. with > >>>> the default celestia.pro). I suppose ChrisL works with the same tools, > >>>> also without problems. > >>> > >>>> For using VS 2008 you merely need to download binary Qt lib built with > >>>> VS 2008 > >>>> http://qt.nokia.com/downloads/windows-cpp-vs2008 > >>>> For using VS2010 you need to download the binary Qt lib built with VS > >>>> 2010 > >>>> http://qt.nokia.com/downloads/windows-cpp-vs2010 > >>> > >>>> It just takes a few minutes. > >>> > >>>> Moreover you have to make sure of course that all the service libs were > >>>> built within the proper system. It is best and straightforward to > >>>> re-compile them for your system... > >>> > >>>> Fridger > >>>>> FWIW, Cosmographia builds fine (albeit with warnings) on that same > >>>> system > >>>>> using Qt Creator with mingw but fails with VSE. > >>>>> > >>>>> Selden > >>>>> > >>>>>> In the early days of Celestia, 3ds was the only supported model > >>>> format. > >>>>>> When cmod was added, I converted all the meshes to the new format > >>>> because > >>>>>> it loads faster (very little preprocessing required at load time for > >>>>>> cmods.) I left the 3ds versions around because 1) they're closer > >>>> to the > >>>>>> original models, and 2) they can be easily viewed and edited in > >>>> modeling > >>>>>> software, whereas cmod files cannot. It shouldn't be necessary to > >>>> keep the > >>>>>> 3ds files around any more. It'd be better to just have a README > >>>> file giving > >>>>>> the original sources of the shape models. Ideally, we'd also > >>>> commit the > >>>>>> scripts required to convert models from their original formats to > >>>> cmods. > >>>>>> --Chris > >>>>>> On Wed, Mar 21, 2012 at 12:28 PM, Andrew Tribick > >>>>>> <ajt...@go...>wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> I've noticed that the src tree has several Visual C++ 6 > >>>>>>> projects/makefiles floating around, would anyone object if we got > >>>> rid > >>>>>>> of these? > >>>>>>> > >>>>>>> There are also several duplicate models: > >>>>>>> > >>>>>>> amalthea.3ds/*amalthea.cmod > >>>>>>> bacchus.3ds/*bacchus.cmod > >>>>>>> castalia.3ds/*castalia.cmod > >>>>>>> deimos.3ds/*deimos.cmod > >>>>>>> epimetheus.3ds/*epimetheus.cmod > >>>>>>> eros.3ds/*eros.cmod/eros.cms > >>>>>>> gaspra.3ds/*gaspra.cmod > >>>>>>> geographos.3ds/*geographos.cmod > >>>>>>> golevka.3ds/*golevka.cmod > >>>>>>> halley.3ds/*halley.cmod > >>>>>>> hyperion.3ds/*hyperion.cmod/hyperion.cms > >>>>>>> ida.3ds/*ida.cmod > >>>>>>> janus.3ds/*janus.cmod > >>>>>>> kleopatra.3ds/*kleopatra.cmod > >>>>>>> ky26.3ds/*ky26.cmod > >>>>>>> larissa.3ds/*larissa.cmod > >>>>>>> pandora.3ds/*pandora.cmod > >>>>>>> phobos.3ds/*phobos.cmod > >>>>>>> phoebe.3ds/*phoebe.cmod > >>>>>>> prometheus.3ds/*prometheus.cmod > >>>>>>> proteus.3ds/*proteus.cmod/proteus.cms > >>>>>>> toutatis.3ds/*toutatis.cmod > >>>>>>> vesta.3ds/*vesta.cmod > >>>>>>> > >>>>>>> * indicates use in the files of the data directory > >>>>>>> > >>>>>>> Do we actually need to keep all these unused meshes around? > >>>>>>> > >>>>>>> Regards, > >>>>>>> Andrew > >>>>>>> > >>>>>>> > >>>>>>> > >>>> ------------------------------------------------------------------------------ > >>>>>>> This SF email is sponsosred by: > >>>>>>> Try Windows Azure free for 90 days Click Here > >>>>>>> http://p.sf.net/sfu/sfd2d-msazure > >>>>>>> _______________________________________________ > >>>>>>> Celestia-developers mailing list > >>>>>>> Cel...@li... > >>>>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers > >>>>>>> > >>>>> > >>>> ------------------------------------------------------------------------------ > >>>>> This SF email is sponsosred by: > >>>>> Try Windows Azure free for 90 days Click Here > >>>>> http://p.sf.net/sfu/sfd2d-msazure > >>>>> _______________________________________________ > >>>>> Celestia-developers mailing list > >>>>> Cel...@li... > >>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > Celestia-developers mailing list > > Cel...@li... > > https://lists.sourceforge.net/lists/listinfo/celestia-developers > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Fridger S. <fri...@de...> - 2012-03-24 16:18:52
|
Selden, congratulations! But these 3 hours spent were entirely superfluous. I have many many times installed new Qt lib/Qt Creator updates during the past years. It never took more than ~ 15 minutes! From the huge amount of time it took for you, I infer that you did not follow my advice to just download the Qt libs (compiled either with VS 2008 or with VS 2010) and the latest version of Qt Creator. Just use these links: http://qt.nokia.com/downloads/windows-cpp-vs2008 OR http://qt.nokia.com/downloads/windows-cpp-vs2010 AND http://qt.nokia.com/downloads/qt-creator-binary-for-windows This only assumes a proper previous installation of VS 2008 Express SP1 or VS 2010 Express SP 1. Note the SP 1 in each case! Moreover, I disagree with some of your new Wiki book entries: > Start Qt Creator > > Be patient: it takes quite a while before it opens its window. (90 seconds on a Dell Latitude E6510 laptop.) This is ridiculous! With my 6 years old DELL D620/ 4GB RAM it just takes 3-4 seconds ;-). > When you run Celestia by clicking on the IDE's green triangle, > it has no problems finding the necessary Qt libraries. However, when > you start Celestia by clicking on its own icon, Celestia doesn't know where > to get the Qt libraries. The easiest workaround is to copy into Celestia's > main directory the files QtCore4.dll, QtGui4.dll, QtOpenGL4.dll and QtXml4.dll. Do you really think that I'd work with this Qt environment DAILY if it was so stupid as you describe ;-). You just misconfigured. Everything will run out of the box without ANY fiddling relative to the default source archive of Celestia.SVN. Just believe me for once. Did you setup a shadow build directory, without making ANY changes at the default celestia.pro file!? Did you use the standard external libs in windows/ with just the 3 DLLs copied into Celestia's root dir? What is your Tool chain and installed Compiler (that you can check in the Profiles department)? Did you avoid installing MinGW?? Fridger On 24.03.2012 16:26, Selden E Ball Jr wrote: > I finally managed to get Celestia to build and run with the Qt interface > by updating to the most recent version of the Qt IDE. It was a quite > frustrating procedure since it took so long (more than 3 hours) > and I had to restart it several times last night and this morning. > > I've started an initial description of the Qt build procedure at > http://en.wikibooks.org/wiki/Celestia/Development/Qt4#Building_Celestia > > I've written some rudimentary instructions for Windows, but it needs > filling out. Someone else will have to write the Linux and MacOS > instructions. > > Selden > > > >> Dear all, > >> I think it would be a great idea if someone would be going ahead and >> write a chapter in the Celestia Wikibook about what is needed to get a >> clean installation of Qt under the different operating systems and >> compilers to run. Especially Linux would probably be beneficial for some >> (myself included). > >> Like Fridger here wrote, which Binary to download and which one not and >> so on. I am also having troubles sometimes when I update the Qt Versions >> because I forget to upgrade the installation path to the Qt binary. > >> But if it finally runs, it builds okay (XP3). > >> Best regards, > >> Christian > >> Am 23.03.2012 00:23, schrieb Selden E Ball Jr: >>> Fridger, >>> >>> Since the VS2008 Express environment builds the non-Qt version of Celestia >>> with no problems at all, I am very relctant to spend the time necessary >>> to set up the environment which is needed to build Celestia under VS2010. >>> You probably did that a long time ago and have fogotten the annoyances >>> involved. >>> >>> A brief description of some of the necessary steps, including getting >>> and building zlib and png libraries (except for their unknown dependencies) >>> from SourceForge, is in the WikiBook at >>> http://en.wikibooks.org/wiki/Celestia/Development/Win32_platform#VS2010 >>> >>> The Windows Celestia dlls that I currently have are >>> iconv.dll intl.dll libiconv-2.dll libintl-8.dll lua5.1.dll and >>> lua51.dll. I just now copied them (again) to the Celestia directory >>> and rebuilt Qt Celestia. QtCreator still complains about the same three >>> missing external symbols: >>> >>>>> unresolved external symbol _libintl_sprintf (in many routines) >>>>> unresolved external symbol _png_set_longmp_fn >>>>> unresolved external symbol _libintl_setlocale >>> >>> It is not at all obvious to me where I could find whatever >>> libraries are needed to provide the missing routines referenced >>> by the Qt build. >>> >>> If they are provided by rebuilding some of the libraries currently >>> provided by the svn, then it seems to me that those rebuilt libraries >>> should be provided in the svn repository. If VS2010 is required >>> in order to build those modified libraries, then I believe that the svn >>> repository should be updated to support building with VS2010 >>> instead of VS2008. >>> >>> s. >>> >>>> Selden. >>> >>>> On 03/22/2012 11:52 PM, Selden E Ball Jr wrote: >>>>> Fridger, >>>>> >>>>> As I mentioned, I'm using Qt-Creator (it's v2.2.0). >>>>> As best I can tell, the Web page >>>>> http://qt.nokia.com/downloads/windows-cpp-vs2008 >>>>> provides a download of a Qt development environment, not just the >>>>> necessary VS libraries. My jnderstanding is that QtCreator already >>>>> includes that development environment. I'm hesitant to install >>>>> the Qt environment in case it would trash the QtCreator environment. >>>>> >>>> I can assure you that you will trash nothing, if you do a complete >>>> installation of the VS 2010 Express compiler (that will also provide the >>>> required tool chain for Qt creator), the matching /binary/ lib download >>>> (see link in previous mail) and the separate /binary/ Qt-creator 2.4.1 from >>>> http://qt.nokia.com/downloads/qt-creator-binary-for-windows >>> >>>> That's all you need and the total installation takes less than 15 min. >>>> During installation un-tick the MinGW option. Installing the Qt SDK >>>> takes much longer and redoubles part of the installation if you got a >>>> complete resident VS 2010 Express. I am doing this procedure now since >>>> several years both on my Windows and my Linux machines, and it has >>>> always worked for me. >>> >>>> As to a deinstallation of VS 2008 Express, there is ample info on the >>>> net. There are rare cases where some parts don't deinstall >>>> straightforwardly. Then the proper procedure is given at MS. >>> >>>>> The errors I get when using QtCreator to build Celestia do seem to be >>>>> related to missing (or unsearched) libraries: >>>>> >>>>> unresolved external symbol _libintl_sprintf (in many routines) >>>>> unresolved external symbol _png_set_longmp_fn >>>>> unresolved external symbol _libintl_setlocale >>>>> >>> >>>> I suppose you did not forget to copy the respective .dll's from >>>> windows/dll/x86 into celestia's root dir? >>> >>>>> Those are the only unresolved symbols that it complains about, though. >>>>> >>>>> s. >>>>> >>>>> >>>>>> Selden, >>>>> >>>>>> On 03/22/2012 07:38 PM, Selden E Ball Jr wrote: >>>>>>> In contrast, I have never been able to get Celestia to build using >>>>>>> Nokia's Qt Creator on that same Win7 x64 system using the SVN's .pro >>>>>>> file. Both VS C++ and mingw options fail. >>>>>> This is really hard for me to understand. I also have a Win 7 64bit OS >>>>>> as well as a XP SP3 one. On the 32bit Win XP, I build with VS 2008 >>>>>> Express, and --since 1 year already -- I build Celestia.SVN with VS >>>>>> 2010 Express under Win 7 most regularly. For Win 7, I use as Tool Chain: >>>>>> "MS Windows SDK for Windows 7 (7.1.7600.0.30514)(x86)". >>>>> >>>>>> MinGW is definitely "off limits" in all my installations for a number of >>>>>> reasons. >>>>>> On both systems I currently use Qt creator = 2.4.1 and Qt 4.8.0. Same on >>>>>> Linux, by the way. >>>>> >>>>>> You did not describe what precisely your persistent Qt creator problems >>>>>> are. I am sure it must be a configuration issue, since I don't >>>>>> encounter any problems ( apart from obvious transient issues >>>>>> occasionally) . Of course, I also build Cosmographia almost daily with >>>>>> Qt creator, since Chris is working so hard there. Same setting, NO >>>>>> MinGW. >>>>> >>>>>> According to my experience, most often, people fiddling with MinGW vs VS >>>>>> 20xx, forget adjusting the celestia.pro statement >>>>> >>>>>> LIBS += /nodefaultlib:libcmt.lib >>>>> >>>>>> and the service libs. >>>>> >>>>>> Here is e.g. a respective summary. >>>>>> http://msdn.microsoft.com/en-us/library/aa267384%28v=vs.60%29.aspx >>>>> >>>>>> In contrast, if you use a standard VS2010 Express and a current Qt, >>>>>> Qt-creator installation, Celestia should build out of the box (i.e. with >>>>>> the default celestia.pro). I suppose ChrisL works with the same tools, >>>>>> also without problems. >>>>> >>>>>> For using VS 2008 you merely need to download binary Qt lib built with >>>>>> VS 2008 >>>>>> http://qt.nokia.com/downloads/windows-cpp-vs2008 >>>>>> For using VS2010 you need to download the binary Qt lib built with VS >>>>>> 2010 >>>>>> http://qt.nokia.com/downloads/windows-cpp-vs2010 >>>>> >>>>>> It just takes a few minutes. >>>>> >>>>>> Moreover you have to make sure of course that all the service libs were >>>>>> built within the proper system. It is best and straightforward to >>>>>> re-compile them for your system... >>>>> >>>>>> Fridger >>>>>>> FWIW, Cosmographia builds fine (albeit with warnings) on that same >>>>>> system >>>>>>> using Qt Creator with mingw but fails with VSE. >>>>>>> >>>>>>> Selden >>>>>>> >>>>>>>> In the early days of Celestia, 3ds was the only supported model >>>>>> format. >>>>>>>> When cmod was added, I converted all the meshes to the new format >>>>>> because >>>>>>>> it loads faster (very little preprocessing required at load time for >>>>>>>> cmods.) I left the 3ds versions around because 1) they're closer >>>>>> to the >>>>>>>> original models, and 2) they can be easily viewed and edited in >>>>>> modeling >>>>>>>> software, whereas cmod files cannot. It shouldn't be necessary to >>>>>> keep the >>>>>>>> 3ds files around any more. It'd be better to just have a README >>>>>> file giving >>>>>>>> the original sources of the shape models. Ideally, we'd also >>>>>> commit the >>>>>>>> scripts required to convert models from their original formats to >>>>>> cmods. >>>>>>>> --Chris >>>>>>>> On Wed, Mar 21, 2012 at 12:28 PM, Andrew Tribick >>>>>>>> <ajt...@go...>wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I've noticed that the src tree has several Visual C++ 6 >>>>>>>>> projects/makefiles floating around, would anyone object if we got >>>>>> rid >>>>>>>>> of these? >>>>>>>>> >>>>>>>>> There are also several duplicate models: >>>>>>>>> >>>>>>>>> amalthea.3ds/*amalthea.cmod >>>>>>>>> bacchus.3ds/*bacchus.cmod >>>>>>>>> castalia.3ds/*castalia.cmod >>>>>>>>> deimos.3ds/*deimos.cmod >>>>>>>>> epimetheus.3ds/*epimetheus.cmod >>>>>>>>> eros.3ds/*eros.cmod/eros.cms >>>>>>>>> gaspra.3ds/*gaspra.cmod >>>>>>>>> geographos.3ds/*geographos.cmod >>>>>>>>> golevka.3ds/*golevka.cmod >>>>>>>>> halley.3ds/*halley.cmod >>>>>>>>> hyperion.3ds/*hyperion.cmod/hyperion.cms >>>>>>>>> ida.3ds/*ida.cmod >>>>>>>>> janus.3ds/*janus.cmod >>>>>>>>> kleopatra.3ds/*kleopatra.cmod >>>>>>>>> ky26.3ds/*ky26.cmod >>>>>>>>> larissa.3ds/*larissa.cmod >>>>>>>>> pandora.3ds/*pandora.cmod >>>>>>>>> phobos.3ds/*phobos.cmod >>>>>>>>> phoebe.3ds/*phoebe.cmod >>>>>>>>> prometheus.3ds/*prometheus.cmod >>>>>>>>> proteus.3ds/*proteus.cmod/proteus.cms >>>>>>>>> toutatis.3ds/*toutatis.cmod >>>>>>>>> vesta.3ds/*vesta.cmod >>>>>>>>> >>>>>>>>> * indicates use in the files of the data directory >>>>>>>>> >>>>>>>>> Do we actually need to keep all these unused meshes around? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Andrew >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>>>>> This SF email is sponsosred by: >>>>>>>>> Try Windows Azure free for 90 days Click Here >>>>>>>>> http://p.sf.net/sfu/sfd2d-msazure >>>>>>>>> _______________________________________________ >>>>>>>>> Celestia-developers mailing list >>>>>>>>> Cel...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>>> This SF email is sponsosred by: >>>>>>> Try Windows Azure free for 90 days Click Here >>>>>>> http://p.sf.net/sfu/sfd2d-msazure >>>>>>> _______________________________________________ >>>>>>> Celestia-developers mailing list >>>>>>> Cel...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>> >>> ------------------------------------------------------------------------------ >>> This SF email is sponsosred by: >>> Try Windows Azure free for 90 days Click Here >>> http://p.sf.net/sfu/sfd2d-msazure >>> _______________________________________________ >>> Celestia-developers mailing list >>> Cel...@li... >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers > > >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> Celestia-developers mailing list >> Cel...@li... >> https://lists.sourceforge.net/lists/listinfo/celestia-developers > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Fridger S. <fri...@de...> - 2012-03-25 00:21:15
|
Selden, On 24.03.2012 22:29, Selden E Ball Jr wrote: > > Fridger, > > Since nobody ever documented the appropriate procedures, NOT true! I described the installation procedure precisely in 2009 as well as in 2010 in the respective shatters.net forums on the same subject... > I did the simplest things needed to install the Qt SDK, > which, by default, insall the packages needed to support > all of the system types supported by Qt. I suspect that's > what makes everything so slow. > I have pointed out many times that installing the SDK takes a horrendously long time and will install all sorts of stuff that we will never need in a Celestia related context. > The resuslts are as I've written. You did not communicate what compiler you were finally using. > > I never did anything to configure any toolchains. OK. Qt Creator looks automatically for usable tool chains and the user can choose among them in the Projects department. The default is usually the best. > > I built Celetia using a fresh download from SourceForge, with no > modifications whatsoever (other than copying the three dlls into > the main Celestia directory). Sounds OK. Did you install MinGW or not?? Its installation can be deactivated during installation of the SDK. It's mainly offered for people still lacking a complete compiler installation (like VS 2008 or VS 2010)... > > It probably would be appropriate for someone experienced in > using the Qt software to write a set of explicit instructions > for using them for building Celestia from scratch, assuming that > *NO* previous development software has been installed. This job is too frustrating, since this discussion has once more demonstrated that people don't follow the instructions ;-) > I'd be willing to test them in a VM, but given the time investment > I've made in my working system, I'm, hopefully understandably, > reluctant to risk trashing it, even if it isn't optimal. > As I emphasized earlier, at any time you may operate several Qt versions in parallel without mutual interference. Additional installations are no problem once you understood the general structure of the Qt environment. Fridger PS: Already in Jan 2008, I was the first one in our Celestia community who succeeded to compile Celestia-Qt with a MSVC compiler (VS 2003 rather than MinGW). Here is the respective "success" mail http://www.shatters.net/forum/viewtopic.php?f=10&t=11773&start=44 > s. > >> Selden, > >> congratulations! But these 3 hours spent were entirely superfluous. I have >> many many times installed new Qt lib/Qt Creator updates during the past years. >> It never took more than ~ 15 minutes! > >> From the huge amount of time it took for you, I infer that you did not follow >> my advice to just download the Qt libs (compiled either with VS 2008 or with >> VS 2010) and the latest version of Qt Creator. > >> Just use these links: > >> http://qt.nokia.com/downloads/windows-cpp-vs2008 >> OR >> http://qt.nokia.com/downloads/windows-cpp-vs2010 > >> AND >> http://qt.nokia.com/downloads/qt-creator-binary-for-windows > >> This only assumes a proper previous installation of VS 2008 Express SP1 or VS >> 2010 Express SP 1. Note the SP 1 in each case! > >> Moreover, I disagree with some of your new Wiki book entries: > >>> Start Qt Creator >>> >>> Be patient: it takes quite a while before it opens its window. (90 seconds on a Dell Latitude E6510 laptop.) > >> This is ridiculous! With my 6 years old DELL D620/ 4GB RAM it just takes 3-4 >> seconds ;-). > >>> When you run Celestia by clicking on the IDE's green triangle, >>> it has no problems finding the necessary Qt libraries. However, when >>> you start Celestia by clicking on its own icon, Celestia doesn't know where >>> to get the Qt libraries. The easiest workaround is to copy into Celestia's >>> main directory the files QtCore4.dll, QtGui4.dll, QtOpenGL4.dll and QtXml4.dll. > >> Do you really think that I'd work with this Qt environment DAILY if it was so >> stupid as you describe ;-). You just misconfigured. > >> Everything will run out of the box without ANY fiddling relative to the >> default source archive of Celestia.SVN. Just believe me for once. > >> Did you setup a shadow build directory, without making ANY changes at the >> default celestia.pro file!? Did you use the standard external libs in windows/ >> with just the 3 DLLs copied into Celestia's root dir? > >> What is your Tool chain and installed Compiler (that you can check in the >> Profiles department)? > >> Did you avoid installing MinGW?? > >> Fridger > > >> On 24.03.2012 16:26, Selden E Ball Jr wrote: >>> I finally managed to get Celestia to build and run with the Qt interface >>> by updating to the most recent version of the Qt IDE. It was a quite >>> frustrating procedure since it took so long (more than 3 hours) >>> and I had to restart it several times last night and this morning. >>> >>> I've started an initial description of the Qt build procedure at >>> http://en.wikibooks.org/wiki/Celestia/Development/Qt4#Building_Celestia >>> >>> I've written some rudimentary instructions for Windows, but it needs >>> filling out. Someone else will have to write the Linux and MacOS >>> instructions. >>> >>> Selden >>> >>> >>> >>>> Dear all, >>> >>>> I think it would be a great idea if someone would be going ahead and >>>> write a chapter in the Celestia Wikibook about what is needed to get a >>>> clean installation of Qt under the different operating systems and >>>> compilers to run. Especially Linux would probably be beneficial for some >>>> (myself included). >>> >>>> Like Fridger here wrote, which Binary to download and which one not and >>>> so on. I am also having troubles sometimes when I update the Qt Versions >>>> because I forget to upgrade the installation path to the Qt binary. >>> >>>> But if it finally runs, it builds okay (XP3). >>> >>>> Best regards, >>> >>>> Christian >>> >>>> Am 23.03.2012 00:23, schrieb Selden E Ball Jr: >>>>> Fridger, >>>>> >>>>> Since the VS2008 Express environment builds the non-Qt version of Celestia >>>>> with no problems at all, I am very relctant to spend the time necessary >>>>> to set up the environment which is needed to build Celestia under VS2010. >>>>> You probably did that a long time ago and have fogotten the annoyances >>>>> involved. >>>>> >>>>> A brief description of some of the necessary steps, including getting >>>>> and building zlib and png libraries (except for their unknown dependencies) >>>>> from SourceForge, is in the WikiBook at >>>>> http://en.wikibooks.org/wiki/Celestia/Development/Win32_platform#VS2010 >>>>> >>>>> The Windows Celestia dlls that I currently have are >>>>> iconv.dll intl.dll libiconv-2.dll libintl-8.dll lua5.1.dll and >>>>> lua51.dll. I just now copied them (again) to the Celestia directory >>>>> and rebuilt Qt Celestia. QtCreator still complains about the same three >>>>> missing external symbols: >>>>> >>>>>>> unresolved external symbol _libintl_sprintf (in many routines) >>>>>>> unresolved external symbol _png_set_longmp_fn >>>>>>> unresolved external symbol _libintl_setlocale >>>>> >>>>> It is not at all obvious to me where I could find whatever >>>>> libraries are needed to provide the missing routines referenced >>>>> by the Qt build. >>>>> >>>>> If they are provided by rebuilding some of the libraries currently >>>>> provided by the svn, then it seems to me that those rebuilt libraries >>>>> should be provided in the svn repository. If VS2010 is required >>>>> in order to build those modified libraries, then I believe that the svn >>>>> repository should be updated to support building with VS2010 >>>>> instead of VS2008. >>>>> >>>>> s. >>>>> >>>>>> Selden. >>>>> >>>>>> On 03/22/2012 11:52 PM, Selden E Ball Jr wrote: >>>>>>> Fridger, >>>>>>> >>>>>>> As I mentioned, I'm using Qt-Creator (it's v2.2.0). >>>>>>> As best I can tell, the Web page >>>>>>> http://qt.nokia.com/downloads/windows-cpp-vs2008 >>>>>>> provides a download of a Qt development environment, not just the >>>>>>> necessary VS libraries. My jnderstanding is that QtCreator already >>>>>>> includes that development environment. I'm hesitant to install >>>>>>> the Qt environment in case it would trash the QtCreator environment. >>>>>>> >>>>>> I can assure you that you will trash nothing, if you do a complete >>>>>> installation of the VS 2010 Express compiler (that will also provide the >>>>>> required tool chain for Qt creator), the matching /binary/ lib download >>>>>> (see link in previous mail) and the separate /binary/ Qt-creator 2.4.1 from >>>>>> http://qt.nokia.com/downloads/qt-creator-binary-for-windows >>>>> >>>>>> That's all you need and the total installation takes less than 15 min. >>>>>> During installation un-tick the MinGW option. Installing the Qt SDK >>>>>> takes much longer and redoubles part of the installation if you got a >>>>>> complete resident VS 2010 Express. I am doing this procedure now since >>>>>> several years both on my Windows and my Linux machines, and it has >>>>>> always worked for me. >>>>> >>>>>> As to a deinstallation of VS 2008 Express, there is ample info on the >>>>>> net. There are rare cases where some parts don't deinstall >>>>>> straightforwardly. Then the proper procedure is given at MS. >>>>> >>>>>>> The errors I get when using QtCreator to build Celestia do seem to be >>>>>>> related to missing (or unsearched) libraries: >>>>>>> >>>>>>> unresolved external symbol _libintl_sprintf (in many routines) >>>>>>> unresolved external symbol _png_set_longmp_fn >>>>>>> unresolved external symbol _libintl_setlocale >>>>>>> >>>>> >>>>>> I suppose you did not forget to copy the respective .dll's from >>>>>> windows/dll/x86 into celestia's root dir? >>>>> >>>>>>> Those are the only unresolved symbols that it complains about, though. >>>>>>> >>>>>>> s. >>>>>>> >>>>>>> >>>>>>>> Selden, >>>>>>> >>>>>>>> On 03/22/2012 07:38 PM, Selden E Ball Jr wrote: >>>>>>>>> In contrast, I have never been able to get Celestia to build using >>>>>>>>> Nokia's Qt Creator on that same Win7 x64 system using the SVN's .pro >>>>>>>>> file. Both VS C++ and mingw options fail. >>>>>>>> This is really hard for me to understand. I also have a Win 7 64bit OS >>>>>>>> as well as a XP SP3 one. On the 32bit Win XP, I build with VS 2008 >>>>>>>> Express, and --since 1 year already -- I build Celestia.SVN with VS >>>>>>>> 2010 Express under Win 7 most regularly. For Win 7, I use as Tool Chain: >>>>>>>> "MS Windows SDK for Windows 7 (7.1.7600.0.30514)(x86)". >>>>>>> >>>>>>>> MinGW is definitely "off limits" in all my installations for a number of >>>>>>>> reasons. >>>>>>>> On both systems I currently use Qt creator = 2.4.1 and Qt 4.8.0. Same on >>>>>>>> Linux, by the way. >>>>>>> >>>>>>>> You did not describe what precisely your persistent Qt creator problems >>>>>>>> are. I am sure it must be a configuration issue, since I don't >>>>>>>> encounter any problems ( apart from obvious transient issues >>>>>>>> occasionally) . Of course, I also build Cosmographia almost daily with >>>>>>>> Qt creator, since Chris is working so hard there. Same setting, NO >>>>>>>> MinGW. >>>>>>> >>>>>>>> According to my experience, most often, people fiddling with MinGW vs VS >>>>>>>> 20xx, forget adjusting the celestia.pro statement >>>>>>> >>>>>>>> LIBS += /nodefaultlib:libcmt.lib >>>>>>> >>>>>>>> and the service libs. >>>>>>> >>>>>>>> Here is e.g. a respective summary. >>>>>>>> http://msdn.microsoft.com/en-us/library/aa267384%28v=vs.60%29.aspx >>>>>>> >>>>>>>> In contrast, if you use a standard VS2010 Express and a current Qt, >>>>>>>> Qt-creator installation, Celestia should build out of the box (i.e. with >>>>>>>> the default celestia.pro). I suppose ChrisL works with the same tools, >>>>>>>> also without problems. >>>>>>> >>>>>>>> For using VS 2008 you merely need to download binary Qt lib built with >>>>>>>> VS 2008 >>>>>>>> http://qt.nokia.com/downloads/windows-cpp-vs2008 >>>>>>>> For using VS2010 you need to download the binary Qt lib built with VS >>>>>>>> 2010 >>>>>>>> http://qt.nokia.com/downloads/windows-cpp-vs2010 >>>>>>> >>>>>>>> It just takes a few minutes. >>>>>>> >>>>>>>> Moreover you have to make sure of course that all the service libs were >>>>>>>> built within the proper system. It is best and straightforward to >>>>>>>> re-compile them for your system... >>>>>>> >>>>>>>> Fridger >>>>>>>>> FWIW, Cosmographia builds fine (albeit with warnings) on that same >>>>>>>> system >>>>>>>>> using Qt Creator with mingw but fails with VSE. >>>>>>>>> >>>>>>>>> Selden >>>>>>>>> >>>>>>>>>> In the early days of Celestia, 3ds was the only supported model >>>>>>>> format. >>>>>>>>>> When cmod was added, I converted all the meshes to the new format >>>>>>>> because >>>>>>>>>> it loads faster (very little preprocessing required at load time for >>>>>>>>>> cmods.) I left the 3ds versions around because 1) they're closer >>>>>>>> to the >>>>>>>>>> original models, and 2) they can be easily viewed and edited in >>>>>>>> modeling >>>>>>>>>> software, whereas cmod files cannot. It shouldn't be necessary to >>>>>>>> keep the >>>>>>>>>> 3ds files around any more. It'd be better to just have a README >>>>>>>> file giving >>>>>>>>>> the original sources of the shape models. Ideally, we'd also >>>>>>>> commit the >>>>>>>>>> scripts required to convert models from their original formats to >>>>>>>> cmods. >>>>>>>>>> --Chris >>>>>>>>>> On Wed, Mar 21, 2012 at 12:28 PM, Andrew Tribick >>>>>>>>>> <ajt...@go...>wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I've noticed that the src tree has several Visual C++ 6 >>>>>>>>>>> projects/makefiles floating around, would anyone object if we got >>>>>>>> rid >>>>>>>>>>> of these? >>>>>>>>>>> >>>>>>>>>>> There are also several duplicate models: >>>>>>>>>>> >>>>>>>>>>> amalthea.3ds/*amalthea.cmod >>>>>>>>>>> bacchus.3ds/*bacchus.cmod >>>>>>>>>>> castalia.3ds/*castalia.cmod >>>>>>>>>>> deimos.3ds/*deimos.cmod >>>>>>>>>>> epimetheus.3ds/*epimetheus.cmod >>>>>>>>>>> eros.3ds/*eros.cmod/eros.cms >>>>>>>>>>> gaspra.3ds/*gaspra.cmod >>>>>>>>>>> geographos.3ds/*geographos.cmod >>>>>>>>>>> golevka.3ds/*golevka.cmod >>>>>>>>>>> halley.3ds/*halley.cmod >>>>>>>>>>> hyperion.3ds/*hyperion.cmod/hyperion.cms >>>>>>>>>>> ida.3ds/*ida.cmod >>>>>>>>>>> janus.3ds/*janus.cmod >>>>>>>>>>> kleopatra.3ds/*kleopatra.cmod >>>>>>>>>>> ky26.3ds/*ky26.cmod >>>>>>>>>>> larissa.3ds/*larissa.cmod >>>>>>>>>>> pandora.3ds/*pandora.cmod >>>>>>>>>>> phobos.3ds/*phobos.cmod >>>>>>>>>>> phoebe.3ds/*phoebe.cmod >>>>>>>>>>> prometheus.3ds/*prometheus.cmod >>>>>>>>>>> proteus.3ds/*proteus.cmod/proteus.cms >>>>>>>>>>> toutatis.3ds/*toutatis.cmod >>>>>>>>>>> vesta.3ds/*vesta.cmod >>>>>>>>>>> >>>>>>>>>>> * indicates use in the files of the data directory >>>>>>>>>>> >>>>>>>>>>> Do we actually need to keep all these unused meshes around? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Andrew >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>> This SF email is sponsosred by: >>>>>>>>>>> Try Windows Azure free for 90 days Click Here >>>>>>>>>>> http://p.sf.net/sfu/sfd2d-msazure >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Celestia-developers mailing list >>>>>>>>>>> Cel...@li... >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>>>>>>>>> >>>>>>>>> >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> This SF email is sponsosred by: >>>>>>>>> Try Windows Azure free for 90 days Click Here >>>>>>>>> http://p.sf.net/sfu/sfd2d-msazure >>>>>>>>> _______________________________________________ >>>>>>>>> Celestia-developers mailing list >>>>>>>>> Cel...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> This SF email is sponsosred by: >>>>> Try Windows Azure free for 90 days Click Here >>>>> http://p.sf.net/sfu/sfd2d-msazure >>>>> _______________________________________________ >>>>> Celestia-developers mailing list >>>>> Cel...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>> >>> >>>> ------------------------------------------------------------------------------ >>>> This SF email is sponsosred by: >>>> Try Windows Azure free for 90 days Click Here >>>> http://p.sf.net/sfu/sfd2d-msazure >>>> _______________________________________________ >>>> Celestia-developers mailing list >>>> Cel...@li... >>>> https://lists.sourceforge.net/lists/listinfo/celestia-developers >>> >>> ------------------------------------------------------------------------------ >>> This SF email is sponsosred by: >>> Try Windows Azure free for 90 days Click Here >>> http://p.sf.net/sfu/sfd2d-msazure >>> _______________________________________________ >>> Celestia-developers mailing list >>> Cel...@li... >>> https://lists.sourceforge.net/lists/listinfo/celestia-developers > > >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> _______________________________________________ >> Celestia-developers mailing list >> Cel...@li... >> https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Andrew T. <ajt...@go...> - 2012-03-28 06:26:57
Attachments:
makefiles.diff.zip
|
Turns out the automake system is now broken because the code to exclude the .mak and .dsp files now cannot find them. The fix is relatively simple (see attachment). Question is whether it is worth doing this or whether we should finally retire automake. Andrew |
From: Fridger S. <fri...@de...> - 2012-03-28 10:25:33
|
On 03/28/2012 08:26 AM, Andrew Tribick wrote: > Turns out the automake system is now broken because the code to > exclude the .mak and .dsp files now cannot find them. The fix is > relatively simple (see attachment). Question is whether it is worth > doing this or whether we should finally retire automake. > > Andrew > In this game it is easy to break something, notably for non-experts. I think we should also have Pat's opinion about all this, since he seems to be professionally associated with Linux packaging and the like. Incidentally, do we have Chris' approval to dismantle the whole traditional Celestia building system? In general, once we have singled out a really satisfactory building & installing scheme it is fine with me to get rid of automake and friends that I never liked very much. Fridger > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > > > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Pat S. <pa...@su...> - 2012-03-28 15:13:17
|
I was going to check in the changes myself; just looking for a spare moment. Automake will always be required. What other tool has a proper "make dist" with error and sanity checking, and proper versioning? I can tell you, all of this qmake and cmake BS really, really angers packagers. These tools lack the most basic of concepts that GNU systems expect, like FHS, standard versioning, and self-containment of build. Don't even think of the fiasco regarding libtool and properly generating shared libraries, though this does not apply to Celestia, thankfully. I have stayed out of the conversation regarding qmake versus cmake, but I may as well make a comment since I'm writing this eMail anyway. They both suck, and so does autotools. However, I agree with Fridger that cmake should be stayed away from. When the KDE guys first started touting it, it really seemed to be a nice departure from autotools. What came out of the process is, IMO, just as complex and otherwise worse than what they had before the switch. Qmake can be "massaged" to support the FHS and a version define, and so on, but it is a little weak on the advanced features. Additionally, as I have been saying for the last eight years or so, it's the KDE3 includes that constantly break the autotools. They've never been well written or properly maintained upstream, and that's largely why coolo dumped them in favour of cmake. Removing KDE3 from autotools and enabling resource generation is not difficult. The additional side-effect would be the kind of out-of-tree building that Fridger (and many others) prefer. --Pat On 28/03/12 02:26 AM, Andrew Tribick wrote: > Turns out the automake system is now broken because the code to > exclude the .mak and .dsp files now cannot find them. The fix is > relatively simple (see attachment). Question is whether it is worth > doing this or whether we should finally retire automake. > > Andrew > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > > > > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Fridger S. <fri...@de...> - 2012-03-28 16:59:40
|
Andrew, it seems your fast SVN delete action of *.mak scripts and *.dsp files has broken the build system substantially. The errors that the user 'revaz' experienced today and which I can confirm are NOT fixed by your patch Here is my output at the first error: make[3]: *** No rule to make target `util.mak', needed by `all-am'. Stop. make[3]: Leaving directory `/home/t00fri/Develop/celestia/src/celutil' make[2]: *** [all-recursive] Error 1 To fix all subsequent errors, all *.mak and *.dsp files are needed. There is presumably another way, but your patch does not suffice for sure. My findings match this shatters.net thread: http://www.shatters.net/forum/viewtopic.php?f=3&t=16854 Fridger On 03/28/2012 08:26 AM, Andrew Tribick wrote: > Turns out the automake system is now broken because the code to > exclude the .mak and .dsp files now cannot find them. The fix is > relatively simple (see attachment). Question is whether it is worth > doing this or whether we should finally retire automake. > > Andrew |
From: Pat S. <pa...@su...> - 2012-03-28 17:20:22
|
I have updated the Makefile.am files such that it should work now. In my test, I can build and make dist without issue. --Pat On 28/03/12 12:59 PM, Fridger Schrempp wrote: > Andrew, > > it seems your fast SVN delete action of *.mak scripts and *.dsp files > has broken the build system substantially. The errors that the user > 'revaz' experienced today and which I can confirm are NOT fixed by your > patch > > Here is my output at the first error: > > make[3]: *** No rule to make target `util.mak', needed by `all-am'. Stop. > make[3]: Leaving directory `/home/t00fri/Develop/celestia/src/celutil' > make[2]: *** [all-recursive] Error 1 > > To fix all subsequent errors, all *.mak and *.dsp files are needed. > There is presumably another way, but your patch does not suffice for sure. > > My findings match this shatters.net thread: > > http://www.shatters.net/forum/viewtopic.php?f=3&t=16854 > > Fridger > > > On 03/28/2012 08:26 AM, Andrew Tribick wrote: >> Turns out the automake system is now broken because the code to >> exclude the .mak and .dsp files now cannot find them. The fix is >> relatively simple (see attachment). Question is whether it is worth >> doing this or whether we should finally retire automake. >> >> Andrew > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > > > > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Fridger S. <fri...@de...> - 2012-03-28 17:46:07
|
Pat, many thanks for your quick "pro" action. While there was a required fix for each Makefile.am (as I suspected) now compilation went without complaints. I'll let the user revaz in shatters.net know that he can start over again ... Fridger On 03/28/2012 07:20 PM, Pat Suwalski wrote: > I have updated the Makefile.am files such that it should work now. In my > test, I can build and make dist without issue. > > --Pat > > On 28/03/12 12:59 PM, Fridger Schrempp wrote: >> Andrew, >> >> it seems your fast SVN delete action of *.mak scripts and *.dsp files >> has broken the build system substantially. The errors that the user >> 'revaz' experienced today and which I can confirm are NOT fixed by your >> patch >> >> Here is my output at the first error: >> >> make[3]: *** No rule to make target `util.mak', needed by `all-am'. Stop. >> make[3]: Leaving directory `/home/t00fri/Develop/celestia/src/celutil' >> make[2]: *** [all-recursive] Error 1 >> >> To fix all subsequent errors, all *.mak and *.dsp files are needed. >> There is presumably another way, but your patch does not suffice for sure. >> >> My findings match this shatters.net thread: >> >> http://www.shatters.net/forum/viewtopic.php?f=3&t=16854 >> >> Fridger >> >> >> On 03/28/2012 08:26 AM, Andrew Tribick wrote: >>> Turns out the automake system is now broken because the code to >>> exclude the .mak and .dsp files now cannot find them. The fix is >>> relatively simple (see attachment). Question is whether it is worth >>> doing this or whether we should finally retire automake. >>> >>> Andrew >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> >> >> >> _______________________________________________ >> Celestia-developers mailing list >> Cel...@li... >> https://lists.sourceforge.net/lists/listinfo/celestia-developers > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Pat S. <pa...@su...> - 2012-03-28 17:47:59
|
On 28/03/12 01:45 PM, Fridger Schrempp wrote: > many thanks for your quick "pro" action. While there was a required fix > for each Makefile.am (as I suspected) now compilation went without > complaints. As mentioned, it was on my to-do list and half-done anyway. --Pat |
From: Andrew T. <ajt...@go...> - 2012-03-28 19:39:08
|
Ok very sorry about that. I think I may step away from the code for a while other than doing further testing as I seem to be being a bit of a destructive influence. Andrew On 28 March 2012 19:47, Pat Suwalski <pa...@su...> wrote: > On 28/03/12 01:45 PM, Fridger Schrempp wrote: >> many thanks for your quick "pro" action. While there was a required fix >> for each Makefile.am (as I suspected) now compilation went without >> complaints. > > As mentioned, it was on my to-do list and half-done anyway. > > --Pat > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Celestia-developers mailing list > Cel...@li... > https://lists.sourceforge.net/lists/listinfo/celestia-developers |
From: Pat S. <pa...@su...> - 2012-03-28 20:18:05
|
On 28/03/12 03:38 PM, Andrew Tribick wrote: > Ok very sorry about that. I think I may step away from the code for a > while other than doing further testing as I seem to be being a bit of > a destructive influence. I really wouldn't take it that way. I think it's a positive change to cleanup some of the old build stuff, and that will invariable introduce some breakage along the way. --Pat |
From: Selden E B. Jr <se...@co...> - 2012-04-02 10:28:43
|
Celestia's version number also needs to be changed in src/celestia/qt/qtappwin.cpp It's also present in other files, but most of them seem to be comments or the equivalent. Is there some way for the version value specified in celestia.pro to be evaluated in source files like qtappwin.cpp ? s. > Hello, > Sorry I haven't got round to testing this before now. > The way that automake is doing it is with defining CONFIG_DATA_DIR during > compilation. I also prefer the use of the sh script to generated the > .desktop file as it provides some level of protection against people > deciding to change PREFIX. > The attached diff file incorporates the following: > - Target name set to "celestia" rather than "celestia-qt4" > - Version number set to 1.7.0 - this and the previous change cause make > dist to output celestia1.7.0.tar.gz rather than celestia-qt40.0.0.tar.gz. I > haven't yet checked whether the make dist output is correct though. > - Put object files into the obj subdirectory > - On Linux, if config.h doesn't exist then create it (do we need this on > other platforms?) > - Use pkg-config to find Lua on Linux (based on discussions in the other > thread) > - Define CONFIG_DATA_DIR on Linux, note that the quote escaping will not > work with qmake < 4.2, if we need to support this there are workarounds at > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392902#22 > - Fridger's install code with modification to use sh to generate the > .desktop file. > The celestia.desktop.sh file goes in src/celestia/qt/data. I've been > building this using your change to qtappwin.cpp. > Andrew > On 28 March 2012 17:55, Fridger Schrempp <fri...@de...> wrote: > > Andrew, > > > > after our long qmake versus cmake dispute, I took up the challenge and > wrote > > a prototype LINUX install target for celestia.pro and qmake. It works well > > and fast and the code is compact and self-explanatory due to qmake's > > object-based syntax. Let me add here already that many more > install-related > > features are announced by Nokia for Qt 3.0. > > > > The coding only took about 30 minutes and this half page is all there is. > > Note that the following code is just added at the end of a /standard/ > > celestia.pro from SVN > > > > unix { > > > > #VARIABLES > > > > isEmpty(PREFIX) { PREFIX = /usr/local} > > > > BINDIR = $$PREFIX/bin > > DATADIR =$$PREFIX/share > > WORKDIR =$$DATADIR/$${TARGET} > > > > #MAKE INSTALL > > > > target.path =$$BINDIR > > > > data.path = $$WORKDIR/data > > data.files = $$CATALOG_SOURCE/* > > flares.path = $$WORKDIR/textures > > flares.files += ../textures/*.jpg ../textures/*.png > > textures.path = $$WORKDIR/textures/medres > > textures.files += $$TEXTURE_SOURCE/*.jpg $$TEXTURE_SOURCE/*.png > > lores_textures.path = $$WORKDIR/textures/lores > > lores_textures.files += $$LORES_TEXTURE_SOURCE/*.jpg \ > > $$LORES_TEXTURE_SOURCE/*.png > > hires_textures.path = $$WORKDIR/textures/hires > > hires_textures.files = $$HIRES_TEXTURE_SOURCE/*.jpg > > models.path = $$WORKDIR/models > > models.files += $$MODEL_SOURCE/*.cmod $$MODEL_SOURCE/*.png > > shaders.path = $$WORKDIR/shaders > > shaders.files += $$SHADER_SOURCE/*.vp $$SHADER_SOURCE/*.fp > > fonts.path = $$WORKDIR/fonts > > fonts.files = $$FONT_SOURCE/*.txf > > scripts.path = $$WORKDIR/scripts > > scripts.files = ../scripts/*.celx > > configuration.path = $$WORKDIR > > configuration.files += $$CONFIGURATION_FILES \ > > $$CONFIGURATION_SOURCE/guide.cel \ > > $$CONFIGURATION_SOURCE/demo.cel \ > > $$CONFIGURATION_SOURCE/controls.txt \ > > $$CONFIGURATION_SOURCE/COPYING \ > > $$CONFIGURATION_SOURCE/README \ > > $$CONFIGURATION_SOURCE/ChangeLog \ > > $$CONFIGURATION_SOURCE/AUTHORS > > > > locale.path = $$WORKDIR/locale > > locale.files = ../locale/* > > > > extras.path = $$WORKDIR/extras > > extras.files = ../extras/* > > extras-standard.path = $$WORKDIR/extras-standard > > extras-standard.files = ../extras-standard/* > > > > desktop.path = /usr/share/applications > > desktop.files += ../src/$${TARGET}.desktop > > > > icon128.path = /usr/share/icons/hicolor/128x128/apps > > icon128.files += ../src/celestia/qt/data/celestia.png > > > > INSTALLS += target data textures lores_textures hires_textures \ > > flares models shaders fonts locale extras extras-standard > configuration > > \ > > desktop icon128 > > > > } > > > > > > > > The complete celestia.pro is attached. To avoid misunderstandings, here > are > > the required steps in short: > > > > 1) use a fresh celestia checkout from SVN and cd to celestia's root dir. > > Replace the celestia.pro file in src/. Create a dir named 'build' and > cd > > to build/. There, type > > > > 2) > qmake -config release ../src/celestia.pro > > > > Using my new install code, qmake now generates a 'make install' target in > > the resulting Makefile. Next type > > > > 3) > make > > > sudo make install > > > > I have not chosen a particular Linux distro here, but I rather wanted to > > remain /generic/ for now. So I took as BINDIR for the celestia-qt4 > > executable /usr/local/bin and correspondingly as working directory > > /usr/local/share/$${TARGET}. Note: the target name of celestia-qt4 > prevents > > accidental overwriting ;-). > > Note also that the *.desktop file name and content is different from > yours. > > Also the icons directory is chosen as > /usr/share/icons/hicolor/128x128/apps. > > All these assignments can be trivially modified in celestia.pro. > > > > The working directory, requires some further explanations. > > > > By default, in Qt, > > > > working directory = ./ (i.e $PWD) > > > > Hence it takes an environment variable CELESTIA_DATA_DIR to point to > another > > one, e.g. /usr/local/share/$${TARGET}. In src/celestia/qt/qtappwin.cpp > there > > was a respective bug. While CELESTIA_DATA_DIR is indeed queried from the > > environment, the code in qtappwin.cpp throws an error message unless > > CELESTIA_DATA_DIR is the empty string! > > > > If it is the empty string, then it is replaced by $PWD (=> "./"). This > > corresponds to the above default assignment. However, if > CELESTIA_DATA_DIR > > is to be NON-empty, an error is thrown! Hence the whole env mechanism > didn't > > work. I have attached a simple patch that should be included for testing. > > > > If celestia is started in a terminal or Qt Creator, the working directory > > actually read by the code is always printed upon startup. This cout<< > debug > > statement will of course be deleted later. Before starting the installed > > celestia-qt4, you need to type (once) in the terminal (or lateron into the > > profile...) > > > >> export CELESTIA_DATA_DIR=/usr/local/share/celestia-qt4 > > > > Then start celestia-qt4. You may also type 'export CELESTIA_DATA_DIR=' > > whence an error occurs at startup since the executable ceases to find the > > data directory now. > > > > Perhaps anyone knows another method to communicate the data directory. > > Please let me know. > > > > Finally, concerning the uninstall target: > > > > Andrew, you complained that upon uninstalling some system dir was not > > removed since it (fortunately) happened to be non-empty. Well as you know > > there are two UNIX ways of removing directories: > > > > 1) rm -r <dir> > > 2) rmdir <dir> > > > > The first one always removes <dir>, while rmdir that is used in qmake > NEVER > > removes non-empty dirs. > > So there is no danger whatsoever. Perhaps we come across a better way > these > > days, but after many careful tests, I am convinced that 'sudo make > > uninstall' is perfectly safe! > > > > In summary, there are a few aspects left for polishing, but things appear > to > > work and the required coding is very simple and transparent. As announced > by > > Nokia, there is more to come with Qt 3.x. > > > > Fridger > > > > |
From: Fridger S. <fri...@de...> - 2012-04-02 16:59:30
|
Selden, the VERSION variable that Andrew added to celestia.pro serves to label the distro name, celestia1.7.0.tar.gz, that is generated from the 'make dist' target that the qmake-generated Makefile includes. The 'make dist' target most probably requires further additions. But I guess we are not in a hurry here ;-) Updating the version in qtappwin.cpp should be sufficient. It leads to a correct version number in 'Help->About Celestia'. I have updated it in SVN provisionally to 1.7.0 as well. Automatic syncing the VERSION variable in celestia.pro with the version in qtappwin.cpp seems hard. But perhaps one of us has a clever idea in this respect. I found that all other occurences of 1.6.0 refer to versions that will not be supported anymore at the 1.7.0 level. (Win32, Linux-KDE, Linux-gtk, Linux-gnome, MAC). Fridger On 04/02/2012 12:21 PM, Selden E Ball Jr wrote: > Celestia's version number also needs to be changed in > src/celestia/qt/qtappwin.cpp > > It's also present in other files, but most of them seem to be > comments or the equivalent. > > Is there some way for the version value specified in celestia.pro > to be evaluated in source files like qtappwin.cpp ? > > s. > > >> Hello, >> Sorry I haven't got round to testing this before now. >> The way that automake is doing it is with defining CONFIG_DATA_DIR during >> compilation. I also prefer the use of the sh script to generated the >> .desktop file as it provides some level of protection against people >> deciding to change PREFIX. >> The attached diff file incorporates the following: >> - Target name set to "celestia" rather than "celestia-qt4" >> - Version number set to 1.7.0 - this and the previous change cause make >> dist to output celestia1.7.0.tar.gz rather than celestia-qt40.0.0.tar.gz. I >> haven't yet checked whether the make dist output is correct though. >> - Put object files into the obj subdirectory >> - On Linux, if config.h doesn't exist then create it (do we need this on >> other platforms?) >> - Use pkg-config to find Lua on Linux (based on discussions in the other >> thread) >> - Define CONFIG_DATA_DIR on Linux, note that the quote escaping will not >> work with qmake< 4.2, if we need to support this there are workarounds at >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392902#22 >> - Fridger's install code with modification to use sh to generate the >> .desktop file. >> The celestia.desktop.sh file goes in src/celestia/qt/data. I've been >> building this using your change to qtappwin.cpp. >> Andrew >> On 28 March 2012 17:55, Fridger Schrempp<fri...@de...> wrote: >>> Andrew, >>> >>> after our long qmake versus cmake dispute, I took up the challenge and >> wrote >>> a prototype LINUX install target for celestia.pro and qmake. It works well >>> and fast and the code is compact and self-explanatory due to qmake's >>> object-based syntax. Let me add here already that many more >> install-related >>> features are announced by Nokia for Qt 3.0. >>> >>> The coding only took about 30 minutes and this half page is all there is. >>> Note that the following code is just added at the end of a /standard/ >>> celestia.pro from SVN >>> >>> unix { >>> >>> #VARIABLES >>> >>> isEmpty(PREFIX) { PREFIX = /usr/local} >>> >>> BINDIR = $$PREFIX/bin >>> DATADIR =$$PREFIX/share >>> WORKDIR =$$DATADIR/$${TARGET} >>> >>> #MAKE INSTALL >>> >>> target.path =$$BINDIR >>> >>> data.path = $$WORKDIR/data >>> data.files = $$CATALOG_SOURCE/* >>> flares.path = $$WORKDIR/textures >>> flares.files += ../textures/*.jpg ../textures/*.png >>> textures.path = $$WORKDIR/textures/medres >>> textures.files += $$TEXTURE_SOURCE/*.jpg $$TEXTURE_SOURCE/*.png >>> lores_textures.path = $$WORKDIR/textures/lores >>> lores_textures.files += $$LORES_TEXTURE_SOURCE/*.jpg \ >>> $$LORES_TEXTURE_SOURCE/*.png >>> hires_textures.path = $$WORKDIR/textures/hires >>> hires_textures.files = $$HIRES_TEXTURE_SOURCE/*.jpg >>> models.path = $$WORKDIR/models >>> models.files += $$MODEL_SOURCE/*.cmod $$MODEL_SOURCE/*.png >>> shaders.path = $$WORKDIR/shaders >>> shaders.files += $$SHADER_SOURCE/*.vp $$SHADER_SOURCE/*.fp >>> fonts.path = $$WORKDIR/fonts >>> fonts.files = $$FONT_SOURCE/*.txf >>> scripts.path = $$WORKDIR/scripts >>> scripts.files = ../scripts/*.celx >>> configuration.path = $$WORKDIR >>> configuration.files += $$CONFIGURATION_FILES \ >>> $$CONFIGURATION_SOURCE/guide.cel \ >>> $$CONFIGURATION_SOURCE/demo.cel \ >>> $$CONFIGURATION_SOURCE/controls.txt \ >>> $$CONFIGURATION_SOURCE/COPYING \ >>> $$CONFIGURATION_SOURCE/README \ >>> $$CONFIGURATION_SOURCE/ChangeLog \ >>> $$CONFIGURATION_SOURCE/AUTHORS >>> >>> locale.path = $$WORKDIR/locale >>> locale.files = ../locale/* >>> >>> extras.path = $$WORKDIR/extras >>> extras.files = ../extras/* >>> extras-standard.path = $$WORKDIR/extras-standard >>> extras-standard.files = ../extras-standard/* >>> >>> desktop.path = /usr/share/applications >>> desktop.files += ../src/$${TARGET}.desktop >>> >>> icon128.path = /usr/share/icons/hicolor/128x128/apps >>> icon128.files += ../src/celestia/qt/data/celestia.png >>> >>> INSTALLS += target data textures lores_textures hires_textures \ >>> flares models shaders fonts locale extras extras-standard >> configuration >>> \ >>> desktop icon128 >>> >>> } >>> >>> >>> >>> The complete celestia.pro is attached. To avoid misunderstandings, here >> are >>> the required steps in short: >>> >>> 1) use a fresh celestia checkout from SVN and cd to celestia's root dir. >>> Replace the celestia.pro file in src/. Create a dir named 'build' and >> cd >>> to build/. There, type >>> >>> 2)> qmake -config release ../src/celestia.pro >>> >>> Using my new install code, qmake now generates a 'make install' target in >>> the resulting Makefile. Next type >>> >>> 3)> make >>> > sudo make install >>> >>> I have not chosen a particular Linux distro here, but I rather wanted to >>> remain /generic/ for now. So I took as BINDIR for the celestia-qt4 >>> executable /usr/local/bin and correspondingly as working directory >>> /usr/local/share/$${TARGET}. Note: the target name of celestia-qt4 >> prevents >>> accidental overwriting ;-). >>> Note also that the *.desktop file name and content is different from >> yours. >>> Also the icons directory is chosen as >> /usr/share/icons/hicolor/128x128/apps. >>> All these assignments can be trivially modified in celestia.pro. >>> >>> The working directory, requires some further explanations. >>> >>> By default, in Qt, >>> >>> working directory = ./ (i.e $PWD) >>> >>> Hence it takes an environment variable CELESTIA_DATA_DIR to point to >> another >>> one, e.g. /usr/local/share/$${TARGET}. In src/celestia/qt/qtappwin.cpp >> there >>> was a respective bug. While CELESTIA_DATA_DIR is indeed queried from the >>> environment, the code in qtappwin.cpp throws an error message unless >>> CELESTIA_DATA_DIR is the empty string! >>> >>> If it is the empty string, then it is replaced by $PWD (=> "./"). This >>> corresponds to the above default assignment. However, if >> CELESTIA_DATA_DIR >>> is to be NON-empty, an error is thrown! Hence the whole env mechanism >> didn't >>> work. I have attached a simple patch that should be included for testing. >>> >>> If celestia is started in a terminal or Qt Creator, the working directory >>> actually read by the code is always printed upon startup. This cout<< >> debug >>> statement will of course be deleted later. Before starting the installed >>> celestia-qt4, you need to type (once) in the terminal (or lateron into the >>> profile...) >>> >>>> export CELESTIA_DATA_DIR=/usr/local/share/celestia-qt4 >>> Then start celestia-qt4. You may also type 'export CELESTIA_DATA_DIR=' >>> whence an error occurs at startup since the executable ceases to find the >>> data directory now. >>> >>> Perhaps anyone knows another method to communicate the data directory. >>> Please let me know. >>> >>> Finally, concerning the uninstall target: >>> >>> Andrew, you complained that upon uninstalling some system dir was not >>> removed since it (fortunately) happened to be non-empty. Well as you know >>> there are two UNIX ways of removing directories: >>> >>> 1) rm -r<dir> >>> 2) rmdir<dir> >>> >>> The first one always removes<dir>, while rmdir that is used in qmake >> NEVER >>> removes non-empty dirs. >>> So there is no danger whatsoever. Perhaps we come across a better way >> these >>> days, but after many careful tests, I am convinced that 'sudo make >>> uninstall' is perfectly safe! >>> >>> In summary, there are a few aspects left for polishing, but things appear >> to >>> work and the required coding is very simple and transparent. As announced >> by >>> Nokia, there is more to come with Qt 3.x. >>> >>> Fridger >>> >>> |
From: Pat S. <pa...@su...> - 2012-04-02 18:15:37
|
On 02/04/12 12:59 PM, Fridger Schrempp wrote: > Updating the version in qtappwin.cpp should be sufficient. It leads to a > correct version number in 'Help->About Celestia'. I have updated it in > SVN provisionally to 1.7.0 as well. Automatic syncing the VERSION > variable in celestia.pro with the version in qtappwin.cpp seems hard. > But perhaps one of us has a clever idea in this respect. It should be as easy as: CELVER = 1.7.0 CXXFLAGS += -DVERSION="$$CELVER" No? --Pat |
From: Pat S. <pa...@su...> - 2012-04-02 18:13:22
|
On 02/04/12 12:01 PM, Fridger Schrempp wrote: > All other occurences of 1.6.0 refer to versions that will not be > supported anymore at the 1.7.0 level. (Win32, Linux-KDE, Linux-gtk, > Linux-gnome, MAC). All Linux instances come from config.h, generated from configure.in. --Pat |