search

FWGS / xash3d-fwgs

Xash3D FWGS engine
1.59k stars 242 forks source link

New library naming scheme proposal #39

Closed a1batross closed 3 years ago

a1batross commented 5 years ago

I propose a new library naming scheme, which will allow to distribute mods and games in single archive to different operating systems and CPUs:

Legend:

The scheme will be:

  1. Client library:

    • client.$ext for Win/Lin/Mac with x86.
    • client_$arch.$ext for Win/Lin/Mac with NON-x86.
    • client_$os_$arch.$ext for everything else.

  2. Menu library:

    • menu.$ext for Win/Lin/Mac with x86.
    • menu_$arch.$ext for Win/Lin/Mac with NON-x86.
    • menu_$os_$arch.$ext for everything else.

  3. Server library:

    • On Win/Lin/Mac with x86, it MUST use the raw gamedll name for corresponding OS field from gameinfo.txt.
    • On Win/Lin/Mac with NON-x86, it MUST use the raw gamedll name for corresponding OS field from gameinfo.txt, but append _$arch before file extension. Like: hl_amd64.so or cs_e2k.so.
    • On everything else, it must use gamedll name from gamedll_linux field, but append _$os_$arch before file extension. Like: hl_haiku_amd64.so or cs_freebsd_armhf.so. Why gamedll_linux and not gamedll? Because it looks more logic that way, most operating systems are *nix-like and share code with Linux, rather than Windows.

  4. Refresh library: not needed, as RefAPI is not stable and it's not intended to distribute with mods.

For any libraries distributed with engine, naming scheme should be used more convenient for OS port.

Issue #0. Inconsistency between ABI and Q_buildarch. Resolution: Change Q_buildarch return value to use Debian-styled architectures list: https://www.debian.org/ports/, which includes a special naming for big/little-endian and hard/soft-float ARM.

Issue #1: Build-system integration. Resolution: extend MACRO_TO_DEST_CPU and MACRO_TO_DESTOS from Waf: https://gitlab.com/ita1024/waf/blob/master/waflib/Tools/c_config.py#L1002, if needed.

a1batross commented 5 years ago

Issue #2(related to #0): Which ARM flavours we actually need to handle?

Following Debian-styled arch names, it will be like this: armhf -- vfp, i.e. runs only on armv7a and has hard-float ABI. armel -- no float acceleration, i.e. runs even on armv4t. Do we need this?

Maybe it would be enough only maintain hard-/soft-float ABI?

a1batross commented 5 years ago

Resolution: Define 5 different kinds of ARM code:

~I hope 32-bit ARM would die as soon as possible~

mittorn commented 5 years ago

armv?l armv?hf

a1batross commented 5 years ago

That's an idea, really.

a1batross commented 5 years ago

Updated.

a1batross commented 5 years ago

Implemented in the latest commits https://github.com/FWGS/xash3d-fwgs/commit/ec18dd95353f8308b5583263e106c7474f899e62 and https://github.com/FWGS/xash3d-fwgs/commit/89a3fd632316cf7dbcbe40a7e69e1aea446b89ae.

a1batross commented 3 years ago

Integration is fully done and it seems working ok.