UNLOZE/sourcemod
10
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
2b1cc43355
sourcemod/core/AMBuilder

168 lines
5.9 KiB
Plaintext
Raw Normal View History

Add VS Preview 2017 as valid compiler (msvc-1911) (#678)
2018-01-28 12:39:23 +01:00
# vim: set sts=2 ts=8 sw=2 tw=99 et ft=python:
More changes for new build system.
2009-08-30 09:46:56 +02:00
import os
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
project = builder.LibraryProject('sourcemod')
Update for latest Blade Symphony SDK
2020-03-11 23:36:25 +01:00
Port build scripts to the new project API.
2014-06-01 04:56:42 +02:00
project.sources += [
'ChatTriggers.cpp',
'ConCmdManager.cpp',
'ConVarManager.cpp',
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
'ConsoleDetours.cpp',
Port build scripts to the new project API.
2014-06-01 04:56:42 +02:00
'CoreConfig.cpp',
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
'EventManager.cpp',
'GameHooks.cpp',
'HalfLife2.cpp',
Port build scripts to the new project API.
2014-06-01 04:56:42 +02:00
'Logger.cpp',
'MenuManager.cpp',
'MenuStyle_Base.cpp',
'MenuStyle_Radio.cpp',
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
'MenuStyle_Valve.cpp',
'MenuVoting.cpp',
'NextMap.cpp',
'PlayerManager.cpp',
'TimerSys.cpp',
'UserMessages.cpp',
'concmd_cleaner.cpp',
'frame_hooks.cpp',
'logic_bridge.cpp',
'pb_handle.cpp',
Port build scripts to the new project API.
2014-06-01 04:56:42 +02:00
'sm_autonatives.cpp',
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
'sm_stringutil.cpp',
Expose some of ICommandLine to plugins.
2014-10-07 23:16:02 +02:00
'smn_commandline.cpp',
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
'smn_console.cpp',
'smn_entities.cpp',
'smn_events.cpp',
'smn_halflife.cpp',
'smn_hudtext.cpp',
'smn_keyvalues.cpp',
'smn_nextmap.cpp',
'smn_player.cpp',
'smn_usermsgs.cpp',
'smn_vector.cpp',
'sourcemm_api.cpp',
'sourcemod.cpp',
Port build scripts to the new project API.
2014-06-01 04:56:42 +02:00
]
Port simple C++ build scripts to AMBuild 2 (bug 5997 part 1, r=ds).
2013-12-30 23:50:56 +01:00
for sdk_name in SM.sdks:
sdk = SM.sdks[sdk_name]
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
for cxx in builder.targets:
if not cxx.target.arch in sdk.platformSpec[cxx.target.platform]:
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
continue
Only build OB-Valve binaries on Mac OS X for now (bug 4392, r=dvander).
2010-05-13 11:18:58 +02:00
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
binary_name = 'sourcemod.' + sdk.ext
More changes for new build system.
2009-08-30 09:46:56 +02:00
Remove use of the Dep API. This is going away.
2020-08-25 05:09:24 +02:00
binary = SM.HL2Config(project, builder, cxx, binary_name, sdk)
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
SM.ConfigureForExtension(builder, binary.compiler)
Split intercom.h into separate headers and reduce shared header inclusion.
2015-08-31 06:27:32 +02:00
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
compiler = binary.compiler
Port simple C++ build scripts to AMBuild 2 (bug 5997 part 1, r=ds).
2013-12-30 23:50:56 +01:00
compiler.cxxincludes += [
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
builder.sourcePath
Port simple C++ build scripts to AMBuild 2 (bug 5997 part 1, r=ds).
2013-12-30 23:50:56 +01:00
]
More changes for new build system.
2009-08-30 09:46:56 +02:00
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
pb_includes = []
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
if sdk.name == 'csgo':
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
pb_includes = [
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
os.path.join(sdk.path, 'common', 'protobuf-2.5.0', 'src'),
os.path.join(sdk.path, 'public', 'engine', 'protobuf'),
os.path.join(sdk.path, 'public', 'game', 'shared', 'csgo', 'protobuf')
]
Update for latest Blade Symphony SDK
2020-03-11 23:36:25 +01:00
elif sdk.name == 'blade':
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
pb_includes = [
Update for latest Blade Symphony SDK
2020-03-11 23:36:25 +01:00
os.path.join(sdk.path, 'common', 'protobuf-2.5.0', 'src'),
os.path.join(sdk.path, 'public', 'engine', 'protobuf'),
os.path.join(sdk.path, 'public', 'game', 'shared', 'berimbau', 'protobuf')
]
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
compiler.cxxincludes += pb_includes
Added initial support for protobuf usermessages on CS:GO (bug 5579, r=asherkin).
2013-01-23 03:43:12 +01:00
Out with the old ConVar accessibility hacks, in with the new.
2018-05-06 18:59:33 +02:00
if compiler.like('msvc'):
Swap _XKEYCHECK_H for _ALLOW_KEYWORD_MACROS, in case it moves to a different header.
2018-05-22 01:54:12 +02:00
compiler.defines += ['_ALLOW_KEYWORD_MACROS']
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
if cxx.target.platform == 'linux':
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
compiler.postlink += ['-lpthread', '-lrt']
Choose correct libprotobuf build for current msvc version on Windows.
2014-03-01 02:44:10 +01:00
Update for latest Blade Symphony SDK
2020-03-11 23:36:25 +01:00
if sdk.name in ['csgo', 'blade']:
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
if compiler.target.platform == 'linux':
if compiler.target.arch == 'x86':
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
lib_path = os.path.join(sdk.path, 'lib', 'linux32', 'release', 'libprotobuf.a')
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
elif compiler.target.arch == 'x86_64':
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
lib_path = os.path.join(sdk.path, 'lib', 'linux64', 'release', 'libprotobuf.a')
compiler.linkflags += ['-Wl,--exclude-libs=libprotobuf.a']
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
elif compiler.target.platform == 'mac':
if compiler.target.arch == 'x86':
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
lib_path = os.path.join(sdk.path, 'lib', 'osx32', 'release', 'libprotobuf-libcxx.a')
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
elif compiler.target.arch == 'x86_64':
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
lib_path = os.path.join(sdk.path, 'lib', 'osx64', 'release', 'libprotobuf-libcxx.a')
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
elif compiler.target.platform == 'windows':
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
msvc_ver = compiler.version
vs_year = ''
Throw configuration error on unsupported compilers (#1029)
2019-11-16 01:40:39 +01:00
if 1900 <= msvc_ver < 2000:
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
vs_year = '2015'
else:
raise Exception('Cannot find libprotobuf for MSVC version "' + str(compiler.version) + '"')
if 'DEBUG' in compiler.defines:
lib_path = os.path.join(sdk.path, 'lib', 'win32', 'debug', 'vs' + vs_year, 'libprotobuf.lib')
else:
lib_path = os.path.join(sdk.path, 'lib', 'win32', 'release', 'vs' + vs_year, 'libprotobuf.lib')
Remove use of the Dep API. This is going away.
2020-08-25 05:09:24 +02:00
compiler.linkflags.insert(0, lib_path)
Port simple C++ build scripts to AMBuild 2 (bug 5997 part 1, r=ds).
2013-12-30 23:50:56 +01:00
Update for latest Blade Symphony SDK
2020-03-11 23:36:25 +01:00
if sdk.name in ['csgo', 'blade']:
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
binary.sources += ['smn_protobuf.cpp']
else:
binary.sources += ['smn_bitbuffer.cpp']
Rewrite DBManager to use the new synchronization primitives (bug 5870, r=fyren).
2013-08-21 09:01:28 +02:00
Update for latest Blade Symphony SDK
2020-03-11 23:36:25 +01:00
if sdk.name != 'blade':
binary.sources += [
'vprof_tool.cpp',
]
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
pb_sources = []
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
if sdk.name == 'csgo':
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
pb_sources = [
64-bit support for CSGO on Linux and macOS (#705)
2017-12-20 08:56:23 +01:00
os.path.join(sdk.path, 'public', 'engine', 'protobuf', 'netmessages.pb.cc'),
os.path.join(sdk.path, 'public', 'game', 'shared', 'csgo', 'protobuf', 'cstrike15_usermessages.pb.cc'),
os.path.join(sdk.path, 'public', 'game', 'shared', 'csgo', 'protobuf', 'cstrike15_usermessage_helpers.cpp'),
]
Update for latest Blade Symphony SDK
2020-03-11 23:36:25 +01:00
elif sdk.name == 'blade':
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
pb_sources = [
Update for latest Blade Symphony SDK
2020-03-11 23:36:25 +01:00
os.path.join(sdk.path, 'public', 'engine', 'protobuf', 'netmessages.pb.cc'),
os.path.join(sdk.path, 'public', 'game', 'shared', 'berimbau', 'protobuf', 'berimbau_usermessages.pb.cc'),
os.path.join(sdk.path, 'public', 'game', 'shared', 'berimbau', 'protobuf', 'berimbau_usermessage_helpers.cpp'),
]
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
if len(pb_sources):
binary.sources += pb_sources
binary.compiler.cxxdefines += ['PROTOBUF_ENABLE']
Added initial support for protobuf usermessages on CS:GO (bug 5579, r=asherkin).
2013-01-23 03:43:12 +01:00
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
if cxx.target.platform == 'mac' and sdk.name in ['csgo']:
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
# We need a proxy library since the game uses libstdc++.
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
pb_binary = SM.HL2Library(builder, cxx, 'pbproxy.' + sdk.ext, sdk)
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
pb_binary.sources += pb_sources
pb_binary.sources += ['pb_proxy.cpp']
pb_binary.compiler.cxxincludes += pb_includes
# Switch from libc++ to libstdc++.
pb_binary.compiler.cxxflags.remove('-stdlib=libc++')
pb_binary.compiler.linkflags.remove('-lc++')
pb_binary.compiler.linkflags.remove('-stdlib=libc++')
pb_binary.compiler.cxxflags.append('-stdlib=libstdc++')
pb_binary.compiler.linkflags.append('-lstdc++')
pb_binary.compiler.linkflags.append('-stdlib=libstdc++')
if '-std=c++1y' in pb_binary.compiler.cxxflags:
pb_binary.compiler.cxxflags.remove('-std=c++1y')
elif '-std=c++14' in pb_binary.compiler.cxxflags:
pb_binary.compiler.cxxflags.remove('-std=c++14')
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
if cxx.target.arch == 'x86':
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
pb_lib_path = os.path.join(sdk.path, 'lib', 'osx32', 'release', 'libprotobuf.a')
Update to AMBuild 2.2. This is a pretty big diff because SourceMod had lots of multi-arch workarounds that can now go away. I've also changed 'x64' to 'x86_64' in many places since this is how AMBuild normalizes it, and it's far too late to pick the shorter string, so we might as well suck it up. The --target-archs parameter has been replaced with --targets. It works the same way. The default behavior for SDK inclusion is now "present" instead of "all" since this lowers the burden of storing many SDKs. Official builds will still be made with --sdks=all.
2020-08-16 06:25:25 +02:00
elif cxx.target.arch == 'x86_64':
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
pb_lib_path = os.path.join(sdk.path, 'lib', 'osx64', 'release', 'libprotobuf.a')
pb_binary.compiler.linkflags.append(pb_lib_path)
SM.binaries += [builder.Add(pb_binary)]
Backed out changeset: 387b27fb575b (bug 5227)
2012-04-14 02:12:24 +02:00
Introduce a pbproxy library to solve macOS linker issues. On SDKs which use protobufs, the engine has objects compiled against a specific version of protobuf. Normally this is fine, we take care on Linux to use the same C++ ABI. On macOS however, we use libc++ to enable C++11 functionality, whereas the protobuf library has been compiled with libstc++. These ABIs are not compatible. To address the problem, we introduce PbHandle. PbHandle is a wrapper around protobuf::Message with two added pieces of state: whether or not the handle "owns" the message (and can free it in its destructor), and whether or not the handle was created by the engine (private) or created by SourceMod (local). Whenever we transfer a protobuf::Message pointer to SourceMod, we must take care to convert it to a Local version first. Whenever we transfer a protobuf pointer to the engine, we must convert it to a Private handle. For platforms with no ABI differences (almost all of them), the handle is a no-op. The private and local localities are compatible and no translation takes place. On macOS, CS:GO does require translation. SourceMod loads a tiny shim library that contains a copy of the protobuf sources compiled against the game's ABI. It then provides serialization and deserialization methods. SourceMod must not interact with the game's protobuf objects without first going through this proxy library. Note that PbHandle is not quite like unique_ptr. It can be converted into a PbHandle that does not destroy the underlying object. This is mainly because UserMessages.cpp has rather complex state, so it is useful to track locality without destroying an object. An unowned PbHandle must not outlive the owning PbHandle.
2020-05-23 07:57:42 +02:00
binary.compiler.cxxdefines += [
'PROTOBUF_PROXY_ENABLE',
'PROTOBUF_PROXY_BINARY_NAME="pbproxy.{}"'.format(sdk.ext),
]
SM.binaries += builder.Add(project)
Reference in New Issue Copy Permalink