Celestia 1.7.0 Development Thread

[onetwothree]

It should be in the link above.

I meant the script used to build an installer.

[cartrite]

The .iss script should be in the installed folder. It is different than the original. I created the script buy using the wizard and having all the needed files in the Celestia folder. In the wizard I just added the folders and the registry lines.

[cartrite]

In case you don't have windows and can't use the installer, this is the script that builds the installer.

celestia.zip

(2.2 KiB) Downloaded 366 times

Added after 17 minutes 1 second:
Anyhow, I don't use the computer I used to build that script anymore. I'm currently using a ASUS VivoBook 17. It's got an Intel I5 processor and the open gl version reported by Celestia is 4.6. I downloaded the setup and installed Celestia on this machine from my former post above. I posted the celestia.iss file above from that download after installation. I'm still in the process of setting up this machine and have not built Celestia yet on it. When I do, I'll provide another installer with the latest build.

Added after 36 minutes 36 seconds:
This script will not work unless it is in the folder that it is compiling.

Added after 5 minutes 20 seconds:
In other words, I put in all the files for Celestia including dll's and ran INNO to compile the installer. The celestia.iss file above will not work on it's own unless it has all the files along side it.

[cartrite]

I built a clone I downloaded today and all the translations seemed to build dll's. Trouble is the translation folders still get installed in C:\. What should the folder be named that all these translation folders belong in? locale?

[onetwothree]

locale

[cartrite]

Well, I put all the folders in a locale folder next to the Celestia root folder. They don't work. They work with the qt5 version I build with linux. They get installed in /usr/local/share/locale. I tried the same thing with windows but nothing. I even got the language setting in windows to have apps use German. That is what I had to set with linux. But still don't work on windows. The dll's get installed with all the other dll's in the root Celestia directory.

Added after 1 minute 20 seconds:
Do they need to be with the folders? I did try that but still nothing.

Added after 5 minutes 32 seconds:
One thing I noticed was Celestia doesn't even look for those dll's. If any other dll is missing, Celestia will not start. I tried to move them to the locale folder so they were not in the root folder with all the other dll's and Celestia started.

[onetwothree]

the full path is locale/be/LC_MESSAGES, replace "be" with your language code. there should be 2 files - celestia.mo & celestia_constellations.mo.

but. i tested with wine and it seems that celestia even doesn't try to load celestia.mo (win interface). but qt works as expected. will check later.

[cartrite]

This computer I'm using now does have the space to install qt5 libs via vcpkg. I can build the qt5 version for windows. I'm sure of it. But what does the community want. A pure windows version or a qt5 version that can run on windows?

[selden]

Unfortunately, both.

FWIW, builds by Janus (maybe a year or so ago) included both executables in the Celestia directory and they both seemed to work OK. He might be able to help.

[cartrite]

The vcpkg version of qt5 did not work. The build went fine but Celestia would not start because of some deployment plugin. I'll have to build qt5 from the qt5 site. I was planning on 5.1.5. Maybe in a few days.

[Janus]

@ cartrite

Would have done more than lurk lately, but the pandemic has kept me swamped.
Whole production floors of things with minor glitches that are never off, but now are, hence only a day off every other week when I am lucky.
Got a note my name had come up, so I looked.

Is your vcpkg set to download/build x86 & x64 both?
It defaults to x86 only, which is annoying when building x64.
If not, you are likely fighting bitness, 32 vs 64, which gets to be a bloody nightmare with anything structured like QT.
Just one reason I like static linking unless there is a specific reason not to, which there sometimes is.
I no longer have QT on my stuff. I can't since they went to requiring accounts.
For reasons specific to my setup and work.Same basic reasons I can never run W10 even if I took enough cranial damage to be willing to.

With QT5, all of the support files are named identically despite subversion, revision, bitness, etc.
The about or file version sections don't contain bitness, and often lack revision data. 5.12 covering 5.12.1, 5.12.2, 5.12.3, which gets messy.
This makes it impossible to really diagnose without lots of frivolous annoying manual checking of versions, and bitness.
Some versions work transparently, most don't, and QT includes no error codes or functions to inform you of the mismatches.

Before I had to remove QT, I was working on prepending bitness sub directories for dlls to the local environment path.
./x86, ./x64, ./arm, ./arm64, which is what I had to do for a custom several years ago, one of them handled the path work for the linux version of the tools.
Perhaps that should be done here
Just a thought.


Janus.

P.S. You might look at creating a pro file if cmake supports them. then compiling with QT creator, which is how I made my QT builds.

Still wanting to get time & learn the how to make a WxWidgets version of celestia, no more split licenses.

[onetwothree]

The vcpkg version of qt5 did not work. The build went fine but Celestia would not start because of some deployment plugin. I'll have to build qt5 from the qt5 site. I was planning on 5.1.5. Maybe in a few days.

You'll face the same issue. You need to run winqtdeploy (in case of official qt builds) or qtdeploy.ps1 (in case of vcpkg) to install required dlls to a target folder. Here is an example: https://github.com/CelestiaProject/Celestia/blob/master/.github/workflows/ci.yml#L70

[cartrite]

I only downloaded built x64 for all vcpkg's. When I was trying to download qt5 last night there was only a x86 version for windows. Linux had a x64 version but windows only a x86. There were older versions available for windows with x64 but I decided to clone with github. When I woke this morning, it seemed to download with success. Anyhow, that seemed to be a waste of time since I would have the same issue. I'll try to run the deployment commands with vcpkg tonight after work.

[cartrite]

For some reason that I'm unaware of Celestia fails to build. I think the vcpkg fmt was updated to version 8 and it throws all kind of warning about fprint being depreciated. But there is finnaly an error while building url.cpp. Got the following terminal output.

Code: Select all

D:\working copy\Celestia\src\celestia\url.cpp(310): message : see reference to function template instantiation 'int fmt
::v8::fprintf<char*,std::basic_string_view<char,std::char_traits<char>>,char>(std::basic_ostream<char,std::char_traits<
char>> &,const S &,const std::basic_string_view<char,std::char_traits<char>> &)' being compiled [D:\working copy\Celest
ia\build1\src\celestia\celestia.vcxproj]
          with
          [
              S=char *
          ]
D:\tools\vcpkg\installed\x64-windows\include\fmt\core.h(1568,59): error C2338: Cannot format an argument. To make type
T formattable provide a formatter<T> specialization: https://fmt.dev/latest/api.html#udt [D:\working copy\Celestia\buil
d1\src\celestia\celestia.vcxproj]
D

This must of just happened because I installed vcpkg on this machine last week. Every thing worked then. But installing qt5 updated a lot of the packages. So fmt must have become incomparable with Celestia code.

[onetwothree]

Sounds like this bug - https://github.com/fmtlib/fmt/issues/2474

[cartrite]

Before I went to work today I did run vcpkg upgrade which was really a downgrade. fmt was down graded to version 7.something. The windows interface now builds fine. No warnings. No errors. I know fmt v8 doesn't like fprint. I guess it may be a bug in the update as far as the reason behind the error. FMT must of just been updated to version 8 a few days ago. Anyhow I'm gonna try and build qt5 again now that I know about running qtdeploy. I'm just wondering if the INNO compiler will add qt5 into setup.exe.

Added after 3 hours 8 minutes:
Another note to add. QT5 is on it's way out. QT6 is now available.

[cartrite]

I got qt5 running but there still seems to be a problem. I couldn't run them command you showed me. All that happened was it was opened with notepad. I did add a system variable QT_PLUGIN_PATH=D:\tools\vcpkg\installed\x64-windows\plugins
I can run it but I don't think others will be able to run it They probably will not have qt5deploy.ps1 on their system. So it would be useless to include qt5 in an installer. The translations still don't work with qt5.

[onetwothree]

The idea is that you run cmake --install then you run qt5deploy.ps1. I don't know how you run it. Have you tried to run powershell explicitly?

[cartrite]

Yes I did try to run it with powershell.. But nothing happened. The shell appeared then disappeared. Celestia still wouldn't start. Maybe, because I installed and built qt5 with vcpkg, it wasn't entered into the registry. It does run on my system with the the environment variable set but I can't see how anyone else could run it if I included the executable in the installer.

On another note, I just built qt5 on linux and noticed a slight problem. The Spice lib does not get installed after the build with make install. I had to manually install it into /usr/local/lib64. I'm gonna see if these translations work and get back to you.

As for the above, I'll try starting the powershell and navigate to the plugin folder and run qtdeploy.ps1 and see what output I get. When I ran it earlier I right clicked on the file and ran it with powershell so there wasn't a way to enter the path. But will this make any difference for other users? If the plugin is required, then it must be on the users' machine.

Added after 38 minutes 25 seconds:
Well, I'm not sure what is supposed to work with the translations, Some is translated and some isn't. This is the linux version of qt5.
Here is a screenshot which should be self explanatory.

The Windows version doesn't work at all. But I'm still not sure that I completed all the steps to display a different language on windows. I installed the German language on both windows and linux. Linux still wouldn't work until I changed a desktop setting to use German. I'm wondering if I'm missing some step on windows.

Added after 36 minutes 17 seconds:
This image shows a bit more about what's getting translated and what isn't. Shows the menu bar.

[cartrite]

I upgraded another drive to suse 15.3 and tried to rebuild celestia on it. Got the following errors.

Code: Select all

[ 84%] Building CXX object src/celengine/CMakeFiles/celengine.dir/asterismrenderer.cpp.o
In file included from /home/cartrite/celestia/Celestia/src/celengine/glshader.h:17:0,
                 from /home/cartrite/celestia/Celestia/src/celengine/shadermanager.h:15,
                 from /home/cartrite/celestia/Celestia/src/celengine/asterismrenderer.h:15,
                 from /home/cartrite/celestia/Celestia/src/celengine/asterismrenderer.cpp:11:
/home/cartrite/celestia/Celestia/src/celengine/glsupport.h:21:10: fatal error: GL/glu.h: No such file or directory
 #include <GL/glu.h/code]
 [code]

Added after 6 minutes 14 seconds:
may be a mistake. I think this was an old version.

Added after 14 minutes 22 seconds:
No it wasn't an old version. I just didn't have glu-dev installed.

Added after 50 seconds:
Somehow it wasn't included in the installation.