Linux build again

[duzenko]

I'm trying to build the project using the steps on our Wiki. 

It just uses up all memory and then kills the terminal window I'm running it from

Any ideas?

https://ibb.co/RTFnLXG

[url=https://ibb.co/RTFnLXG][img]https://i.ibb.co/RTFnLXG/image.png[/img][/url]

Surely 16GB should be sufficient for make -j?

[duzenko]

Then, if I try make -j4 it does not bomb out but gives a miriad of undefined reference errors

https://ibb.co/HTFX3mc

[nbohr1more]

I have 8gb and it compiles with no issue here. ( Linux Mint 19.3 )

One thing I do is limit the number of threads to your core count:

make -j$(nproc)

[stgatilov]

11 hours ago, duzenko said:

Then, if I try make -j4 it does not bomb out but gives a miriad of undefined reference errors

https://ibb.co/HTFX3mc

Maybe you don't have C compiler?
These files are built along with the rest of our code.

[duzenko]

1 hour ago, stgatilov said:

Maybe you don't have C compiler?
These files are built along with the rest of our code.

https://ibb.co/BfvgnGk

[stgatilov]

If I had such problem, I'd look for the object files of GLAD, where these functions are defined.
If they are present, then run objdump to check that the missing symbols are indeed there or missing (they might have slightly different name for instance).
If they are missing, then review the whole compilation log for appropriate .c files.

[duzenko]

22 hours ago, stgatilov said:

If I had such problem, I'd look for the object files of GLAD, where these functions are defined.
If they are present, then run objdump to check that the missing symbols are indeed there or missing (they might have slightly different name for instance).
If they are missing, then review the whole compilation log for appropriate .c files.

I actually can't find any .obj's - where are they supposed to be? Near their .cpp's?

[OrbWeaver]

Linux builds don't product .obj files. The equivalent on Unix is .o

[duzenko]

17 minutes ago, OrbWeaver said:

Linux builds don't product .obj files. The equivalent on Unix is .o

Neither do I see any .o files

[stgatilov]

Object files should be inside build\linux64\CMakeFiles\TheDarkMod.dir

Actually, they are in a similar location on Windows too.
Saving intermediate build files near source code is very annoying

[duzenko]

It's crazy

I still don't get any .o files or even build\linux64 folder

However make -j$(nproc) succeeds

EDIT

Actually, I do get the .o files but under build/CMakeFiles/TheDarkMod.dir

[stgatilov]

8 minutes ago, duzenko said:

It's crazy

I still don't get any .o files or even build\linux64 folder

However make -j$(nproc) succeeds

Ok, I think it depends on how you ran CMake.

This is the script use:

cd ../darkmod_src
cmake -B build/linux64 -DCMAKE_BUILD_TYPE=Release
cmake --build build/linux64 -j 6
cd ../darkmod

If you did not set it, then you have it in some different place.

[duzenko]

Somehow I got it to the point where I can debug the code in VSCode

However the mouse cursor only moves when the game console is active

Any clues?

[stgatilov]

I sometimes have mouse cursor lockup due to messing with game console, and pressing Alt a few times usually fixes it. Unfortunately, Alt is a system hotkey, at least in Ubuntu.

Aside from that... use windowed mode? tweak some in_XXX cvars?

[duzenko]

I remember in the good old scons days we could change something and the second compile would be fast. Now every time I run make it just rebuilds the whole codebase. Is there a way to quickly edit and run?

[stgatilov]

7 minutes ago, duzenko said:

I remember in the good old scons days we could change something and the second compile would be fast. Now every time I run make it just rebuilds the whole codebase. Is there a way to quickly edit and run?

CMake + make is no different from that!

When I run my script, it only compiles the cpp files that have changed.
Of course, with massive PCH you often have to recompile everything, which is not a problem for Windows, but a lot of time for Linux.

Also, there are some first steps (like creating PCH) which take much time, which is rather annoying too.

[OrbWeaver]

Windowed mode + console is the only way I can get the mouse back on Linux. I think it's unavoidable: the game is capturing the mouse for freelook and does not give it back until you do something which interrupts the game, e.g. bringing down the console.

[nbohr1more]

21 minutes ago, OrbWeaver said:

Windowed mode + console is the only way I can get the mouse back on Linux. I think it's unavoidable: the game is capturing the mouse for freelook and does not give it back until you do something which interrupts the game, e.g. bringing down the console.

This still happens when "in_grabMouse" is set to 1 ?

[duzenko]

22 minutes ago, OrbWeaver said:

Windowed mode + console is the only way I can get the mouse back on Linux. I think it's unavoidable: the game is capturing the mouse for freelook and does not give it back until you do something which interrupts the game, e.g. bringing down the console.

You mean you have this problem as well? Did it start last year after switch to GLFW?

[duzenko]

Just now, nbohr1more said:

This still happens when "in_grabMouse" is set to 1 ?

The problem with in_grabMouse 0 is that it loses cursor in windowed mode

[OrbWeaver]

23 hours ago, duzenko said:

You mean you have this problem as well? Did it start last year after switch to GLFW?

It's been like that for as long as I can remember, and I never really considered it a problem as such. This is a 3D game with constant mouselook — I expect it to grab the mouse while it is in the foreground.

23 hours ago, nbohr1more said:

This still happens when "in_grabMouse" is set to 1 ?

With in_grabMouse 1 I get a permanently grabbed mouse, as if I were playing the game exclusively. Bringing down the console releases the mouse, as does Alt+Tab or Super+Tab to another application.

With in_grabMouse 0 the normal cursor displays on top of the window, in addition to the TDM cursor (if on a menu screen). If the cursor is moved outside of the window, the game stops receiving mouse events, which means there is a limit to how far you can rotate the player camera. This is probably useful for testing GUIs and menus but doesn't seem that useful for actual player navigation.