Details

The --without-lobby flag from rP14098 and rP14113 doesn't exclude all lobby code that it could.

But the expected behavior is that if the flag is passed, that there will be hard compile errors if some author referred lobby code but lobby was not meant to be built.

The patch arose from D2271 which adds glooxwrapper ToJSVal conversions in lobby/scripting/ and thus must either add the macro or drop the folder, and the latter seems more like what was ordered.

Test Plan

Compile --without-lobby. Consider that glooxwrapper can be built standalone using build-shared-glooxwrapper and thus sounds like it shouldn't have the config2 guard.
Notice that one can insert invalid cpp code to the glooxwrapper files if building --without-lobby so as to confirm that this file will be excluded in that case.
Notice that excluding the #include files also means that the source files can be distributed with the source/lobby/ folder being erased, so there is advantage to having that excluded.

flag is fraud, because most of the lobby code (especially XmppClient and half of the JSInterface) are still compiled, the flag only unsubscribes few JSinterface functions.

So that is false in fact.
The XmppClient.cpp has not been compiled if --without-lobby was passed, because the source directories for the lobby project if --without-lobby was enabled excluded the lobby/ folder but included the lobby/scripting/ folder.
It still seems correct to exclude all lobby code (including IXmppClient.cpp), since that is what the two words --without-lobby mean, what the user may reasonably expect.

(The interface IXmppClient is useful regardless, because it allows implementing the lobby with a different library than gloox for example.)

(There won't be an IXmppClient object, but the references are still valid, when they could throw compile errors, example is the StunClient use)

The main problem with removing source/lobby/scripting/ entirely is that there is one JS function HasXmppClient that is used in 34 places.
The choices are:

Register JSInterface function HasXmppClient even on --without-lobby.

Add a global helper HasXmppClient and use that in those 34 places..

Change every Engine.HasXmppClient() to Engine.HasXmppClient && Engine.HasXmppClient() in 34 places.

is contrary to the objective of dropping lobby C++ code. It would yield ugly C++ code (registering a stray function in ScriptFunctions.cpp? that would start compromising the rework that had carefully split it into multiple files.)

is contrary to the idea of removign all functions from gui/common/. That idea arises from the fact that all of the functions are unrelated (i.e. logical fragmentation), and secondly many of the GUI JS global functions are used only by 2 or 3 GUI pages, not by 10 of them (so not really global only a bit more local that local to one page..) With #5387 I hoped to make that a bit more clean. There were already some commits in the past years to that folder that removed functions from there.

Another issue with that global helper function is that it hides the fact that every JS code didnt consider the fact that C++ code can be dropped, and that the JS GUI should account for that - rather than only checking whether we're currently connected via Xmpp!

Doesn't have the two conceptual problems above. It makes it so that every JS code has to check whteher lobby support is compiled in and then test for behaving appropriately. The disadvantage is touching 34 conditions and making code a bit longer. In most cases being disconnected is treated equally to not having C++ lobby support. However in principle the code should always first consider whether there is support and then start deciding later what it wants to do if there is support. Example: The option g_Checkboxes.rating in gamesetup.js can be removed entirely if there is no such support, rather than adding the option but hiding it.

So there are three choices that are all ugly, but the last one is the one that seems ugly and correct.