foclassic icon indicating copy to clipboard operation
foclassic copied to clipboard

Replace .lib files with source

Open ghost2238 opened this issue 6 years ago • 5 comments

It's pretty janky to depend on .lib files and it causes interopability issues when moving between compilers. Also, not all libraries have prebuilt lib files so we'd need to build them manually anyway to get the latest version.

Some libraries are already included as source, which is a good thing.

Get new versions of the following libraries:

I think it's best if we simply add those as Libs projects in the same way as Acm, DatFile, GLEW, Zlib etc.

ghost2238 avatar Sep 20 '18 22:09 ghost2238

FLTK, oh sweet, sweet FLTK... i really want it go, but maybe that's just me. On point: when possible, we should check if given library have official git repository/mirror add it as git submodule. If they use cmake on top of that, it's jackpot for me. If they don't, we can always cook our own target, similar to current band-aid for AngelScript, zlib, etc.

wipe2238 avatar Sep 20 '18 22:09 wipe2238

Sounds like a plan regarding third party libs and git.

As for FLTK, we can definitely let it rest. For the stuff that it's currently used for, I don't see why we can't simply use Win32. It's not that hard. Linux server can use CLI/TUI.

Best thing though would be to decouple Server and UI, making it possible to create frontends with C# + some UI toolkit or even just a webclient (HTML/CSS/JS).

ghost2238 avatar Sep 20 '18 23:09 ghost2238

Tossed most of library folders. Header-only (which are added as interface targets) and lib-only. It's "elegant dirt" - it's ready for replacing but at this moment aimed to keep functionality, not having nice and clean cmake setup.

  • IL cannot live without jpeg/png and in theory could be merged into one target. However png is used by server so it should be separated.
  • incidentally made ogg/vorbis as single target, most likely should be separated when/if source arrives
  • there's meh code in 3dStuff which needs glew/glu even for DX targets
  • theora is used by ClientGL only (?)
set( DX_LIBS d3d9 dxguid dxerr d3dxof glew glu32 )
set( GL_LIBS fltkgl glew glu32 opengl32 theora )

set( ASCOMPILER_LIBS ${FOCLASSIC_LIBS} )
set( CLIENT_LIBS     ${FOCLASSIC_LIBS} acm fltk il jpeg ogg png portaudio )
set( MAPPER_LIBS     ${FOCLASSIC_LIBS} fltk il jpeg png )
set( SERVER_LIBS     ${FOCLASSIC_LIBS} distorm fltk png )

More or less. There's still lot of awful #pragma comment for windows libs, that's not sorted out fully yet. Most likely gotta nuke Common.h from orbit first.


@ghost2238

I don't see why we can't simply use Win32. It's not that hard. Linux server can use CLI/TUI.

That's replacing 1 thing with 2 different, eh. How i think splitting current Server target should go:

  • Server static library, basically FOServer class without anything else
  • ServerUI executable = Server library + interface handling With such split we're free to experiment with different libs for server window without being blocked by it until we're happy with results. We keep releasing ServerFLTK to public while we work on ServerSDL2/ServerSFML and shiny new window fantasies. I'd pick SDL2/SFML for a job as they are very virus-like; while not much to infect server-side, it can spread over some of Client/Mapper tasks - keyboard, simple drawing, etc.

As for CLI, it's simply another ServerUI variation. In FOnline it's like this (ignoring 64bit builds):

  • FOnlineServer.exe handles UI
  • FOnlineServer.exe handles headless - StartService()
  • FOnlineServer handles UI
  • FOnlineServerDaemon handles headless/cli - fork() I'd rather release 2 executables per platform - 1 for UI, 1 for headless/cli, without mixing both (not even fully...) on one platform and separating on another. KISS.

wipe2238 avatar Oct 05 '18 22:10 wipe2238

That separation sounds totally reasonable.

ghost2238 avatar Oct 06 '18 17:10 ghost2238

Binary libs are now in LIB.bin/; after it will be applied to master branch (read: v3 release), migration to sources can finally start. If done earlier, there can and will be issues with git when jumping between branches. Should have though about that earlier...

  • all changes to be done in separate branch
  • sources are to be placed in pre-rename dir as submodule with lowercase lib name git submodule add --name [lowercase lib name] -b [branch] http://url/ Source/Libs/[lowercase lib name]
  • binary dirs should stay until everything is done; in case of any screwup along the way, going back to binary version will be much easier
  • fltk sources should be done as first and switch merged into dev and finally master that's against V15 policy, but sooner or later there will be important non-fltk warning missed due to warnflood

wipe2238 avatar Nov 09 '18 12:11 wipe2238