Bug #1323

Cmake with snowballs

Added by shuawinn about 8 years ago. Updated over 7 years ago.

Status:Closed Start date:06/22/2011
Priority:Normal Due date:
Assignee:kervala % Done:

100%

Category:Build
Target version:Version 0.9.0

Description

Tried configuring Cmake to use snowballs. When I built the install project inside VS2008, I checked the default directory for the installation and no snowball files were installed. I checked the build log and there is no mention of it either.

sb.diff (3.3 kB) Magnifier dfighter, 06/22/2011 10:37 pm

sb2.diff (3.7 kB) Magnifier dfighter, 06/23/2011 06:03 pm

sb3.diff (4.8 kB) Magnifier dfighter, 06/23/2011 07:00 pm

sb4.diff (7.5 kB) Magnifier dfighter, 06/23/2011 07:53 pm

nel_launcher_qt.diff (841 Bytes) Magnifier molator, 08/20/2011 06:49 pm

snowballs.diff (835 Bytes) Magnifier molator, 08/22/2011 03:31 pm

snowballs2.diff (994 Bytes) Magnifier molator, 08/22/2011 03:38 pm

History

#1 Updated by shuawinn about 8 years ago

shuawinn wrote:

Tried configuring Cmake to use snowballs. When I built the install project inside VS2008, I checked the default directory for the installation and no snowball files were installed. I checked the build log and there is no mention of it either.

Commented out in cmake, just needs prebuilt Nel libraries to find them.

#2 Updated by dfighter about 8 years ago

Builds more or less with these changes.
The snowballs frontend service fails with this error tho


1>Linking...
1>MSVCRTD.lib(crtexe.obj) : error LNK2019: unresolved external symbol main referenced in function __tmainCRTStartup
1>E:\projects\ryzom_new\ryzom\build\bin\Debug\snowballs_frontend_service.exe : fatal error LNK1120: 1 unresolved externals

#3 Updated by molator about 8 years ago

I switched the subsystem from Console to Windows to remove that issue.

#4 Updated by dfighter about 8 years ago

I can confirm that, changing the subsystem really fixes the link error.
Updated my diff to reflect this change.

#5 Updated by rti about 8 years ago

Without having looked into the code... is it possible that the service does not implement main() but WinMain()?
If this is the case, changing the program entry point signature might be more cross-platform :)

#6 Updated by kervala about 8 years ago

rti wrote:

Without having looked into the code... is it possible that the service does not implement main() but WinMain()?
If this is the case, changing the program entry point signature might be more cross-platform :)

Like dfighter proposed, Adding WIN32 to ADD_EXECUTABLE is the right fix for that :) It doesn't break anything on other platforms (it's simply ignored).

WinMain is for DLLs and GUI applications (without console) under Windows.

main is for console applications.

Qt is using a trick, they created a qtmain library which implements WinMain and call your main.

You can too force the use of main instead of WinMain for GUI applications but it's not the right way to do it.

#7 Updated by dfighter about 8 years ago

Another update, now "building" the INSTALL project will work too. It had the wrong Qt search path set up and it was referring to a Data directory that doesn't exist.
Also I think I will work a bit on it, and make it "unified" like the Ryzom projects are so that we will only have to select the client and server once in the main CMake config dialog. ^^

#8 Updated by rti about 8 years ago

I see. So I assume it is the NeL service creation voodoo which creates the WinMain() on windows and would create main() on other platforms.
I should have looked into the code :)

#9 Updated by dfighter about 8 years ago

No rti, that WIN32 is CMake.
The service creation voodoo magic macro is called "NLNET_SERVICE_MAIN".

#10 Updated by rti about 8 years ago

Yes, I understand.
And NLNET_SERVICE_MAIN generates the service's main()/WinMain() function. Correct?

I just thought in the beginning there is a hardcoded WinMain() function in the code.
But since the NeL macro is used, everything is fine and I should have just shut up in the first place. :)

#11 Updated by dfighter about 8 years ago

Yes it does. :)


#if defined(NL_OS_WINDOWS) && defined(_WINDOWS)
#define NLNET_SERVICE_MAIN(__ServiceClassName, __ServiceShortName, __ServiceLongName, __ServicePort, __ServiceCallbackArray, __ConfigDir, __LogDir) \
 \
int APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) \
{ \
    NLMISC::CApplicationContext    serviceContext; \
    __ServiceClassName *scn = new __ServiceClassName; \
    scn->setArgs (lpCmdLine); \
    createDebug(NULL,!scn->haveLongArg("nolog"));\
    scn->setCallbackArray (__ServiceCallbackArray, sizeof(__ServiceCallbackArray)/sizeof(__ServiceCallbackArray[0])); \
    sint retval = scn->main (__ServiceShortName, __ServiceLongName, __ServicePort, __ConfigDir, __LogDir, __DATE__" "__TIME__); \
    delete scn; \
    return retval; \
}

#else
#define NLNET_SERVICE_MAIN(__ServiceClassName, __ServiceShortName, __ServiceLongName, __ServicePort, __ServiceCallbackArray, __ConfigDir, __LogDir) \
 \
int main(int argc, const char **argv) \
{ \
    NLMISC::CApplicationContext serviceContext; \
    __ServiceClassName *scn = new __ServiceClassName; \
    scn->setArgs (argc, argv); \
    createDebug(NULL,!scn->haveLongArg("nolog"));\
    scn->setCallbackArray (__ServiceCallbackArray, sizeof(__ServiceCallbackArray)/sizeof(__ServiceCallbackArray[0])); \
    sint retval = scn->main (__ServiceShortName, __ServiceLongName, __ServicePort, __ConfigDir, __LogDir, __DATE__" "__TIME__); \
    delete scn; \
    return retval; \
}

#endif

#12 Updated by dfighter about 8 years ago

Ok here's the latest diff :D
  • Removed some duplicate calls to package find.
  • It will now only look for Qt if WITH_QT is selected.
  • Removed the BUILD_SERVER, BUILD_CLIENT, ENABLE_SOUND options, and now it will use WITH_SNOWBALLS_CLIENT and WITH_SNOWBALLS_SERVER

#13 Updated by shuawinn about 8 years ago

Molator found a fix the source files for running the server end of things. The program is looking in an incorrect directory for the config files. They need to have an update at the end of the file when the NLNET_SERVICE_MAIN is called. Collision works fine but the FES, Chat, and POS files need to be fixed. I'm still looking for a fix for the client, as the binary still thinks the default for the config file isn't where it actually is.

#14 Updated by kervala about 8 years ago

  • Category set to Build
  • Status changed from New to Assigned
  • Assignee set to kervala

#15 Updated by sfb about 8 years ago

  • Status changed from Assigned to Resolved
  • Target version set to Version 0.9.0

This was completed in r1770 - sorry I was unaware that there was an issue open.

#16 Updated by kervala about 8 years ago

  • % Done changed from 0 to 100

#17 Updated by molator about 8 years ago

I have added in code\nelns\login_system\nel_launcher_qt\CMakeLists.txt :
${QT_QTMAIN_LIBRARY} in TARGET_LINK_LIBRARIES() to avoid the WinMain issue.

#18 Updated by molator about 8 years ago

Here come the little patch.

#19 Updated by kervala almost 9 years ago

Thanks dfighter and molator for your patch :)

#20 Updated by molator almost 9 years ago

Snowballs client no longer looks for the config file next to the binary.
Here a puny patch to temporary fix that issue.

#21 Updated by molator almost 9 years ago

Beware it's windows only.

#22 Updated by molator almost 9 years ago

The same patch but with linux compatibility.

#23 Updated by sfb over 7 years ago

  • Status changed from Resolved to Closed

If anyone else dives into the unholy depths of Snowballs please open a new issue with your specific problem.

Also available in: Atom PDF