search

rotators / foclassic

FOnline Community Edition (r412 base)
https://rotators.fodev.net/foclassic/
GNU General Public License v3.0
42 stars 5 forks source link

Replace .lib files with source #6

Open ghost2238 opened 6 years ago

ghost2238 commented 6 years ago

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.

wipe2238 commented 6 years ago

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.

ghost2238 commented 6 years ago

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).

wipe2238 commented 6 years ago

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.

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.
ghost2238 commented 6 years ago

That separation sounds totally reasonable.

wipe2238 commented 6 years ago

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...