Package manager support

[ReallySnazzy]

Is your feature request related to a problem? Please describe.
Vcpkg or conan support help alleviate the setup for multiple libraries in a project. They help to get started quickly with a framework while still allowing other libraries to be added quickly.

Describe the solution you'd like
Rather than premade build setups, I think that having vcpkg or conan support would enable more ambitious discord bots to be created faster.

Describe alternatives you've considered

Additional context

Tasks added by @braindigitalis

• vcpkg
• xmake
• AUR
• SW Network
• Libhunt
• gentoo emerge/GURU
• void linux XBPS
• FreeBSD Ports/Packages
• apt, ppa
• conan
• brew

[SirLynix]

I added DPP to xmake repository (see xmake-io/xmake-repo#1222), with my changes it compiles fine on Windows, MinGW, Linux, macOS in both dynamic and static linking.

Since xmake is able to handle dependencies (will find libraries on the machine like cmake but is able to download and compile them if it doesn't find them), I managed to build the lib using a very short xmake.lua.

Usually, xmake packages use CMake to build CMake libraries, but the way dependencies are handled on DPP doesn't help much (mostly because they are embedded). Which is why I patched nlohmann/fmt out of the lib.

I also fixed the export.h header which made static linking impossible on Windows, here's the diff:

diff --git a/include/dpp/export.h b/include/dpp/export.h
index b7b35b5..838f79d 100644
--- a/include/dpp/export.h
+++ b/include/dpp/export.h
@@ -24,25 +24,29 @@
 // Investigate: MSVC doesn't like this
 //static_assert(__cplusplus >= 201703L, "D++ Requires a C++17 compatible compiler. Please ensure that you have enabled C++17 in your compiler flags.");
 
-#ifdef DPP_BUILD
+#ifndef DPP_STATIC
 
-	#ifdef _WIN32
-		#include <dpp/win32_safe_warnings.h>
-	#endif
+	#ifdef DPP_BUILD
+
+		#ifdef _WIN32
+			#include <dpp/win32_safe_warnings.h>
+		#endif
 
-	#ifdef _WIN32
-		#define DPP_EXPORT __declspec(dllexport)
+		#ifdef _WIN32
+			#define DPP_EXPORT __declspec(dllexport)
+		#else
+			#define DPP_EXPORT
+		#endif
 	#else
-		#define DPP_EXPORT
+		#ifdef _WIN32
+			#define DPP_EXPORT __declspec(dllimport)
+		#else
+			#define DPP_EXPORT
+		#endif
 	#endif
+
 #else
-	#ifdef _WIN32
-		#define DPP_EXPORT __declspec(dllimport)
-		/* This is required otherwise fmt::format requires additional file linkage to your project */
-		#define FMT_HEADER_ONLY
-	#else
-		#define DPP_EXPORT
-	#endif
+	#define DPP_EXPORT
 #endif
 
 #ifndef _WIN32

[braindigitalis]

nlohmann and fmt are header only. it would be nicer if they weren't patched out, because we test with specific versions and not just whatever the latest is which could cause support issues

[SirLynix]

xmake can be instructed to use a specific version of nlohmann/fmt.
The main issue here is that by embedding a specific version of those libraries (and not putting them in a namespace), you conflict with the user nlohmann/fmt libs (obligating them to use the very same version you're using for API/ABI compatibility).

Since these libraries are very well tested, I think it would be better to not embed them to prevent such issues.

[braindigitalis]

I added DPP to xmake repository (see xmake-io/xmake-repo#1222), with my changes it compiles fine on Windows, MinGW, Linux, macOS in both dynamic and static linking.

Since xmake is able to handle dependencies (will find libraries on the machine like cmake but is able to download and compile them if it doesn't find them), I managed to build the lib using a very short xmake.lua.

Usually, xmake packages use CMake to build CMake libraries, but the way dependencies are handled on DPP doesn't help much (mostly because they are embedded). Which is why I patched nlohmann/fmt out of the lib.

I also fixed the export.h header which made static linking impossible on Windows, here's the diff:

diff --git a/include/dpp/export.h b/include/dpp/export.h
index b7b35b5..838f79d 100644
--- a/include/dpp/export.h
+++ b/include/dpp/export.h
@@ -24,25 +24,29 @@
 // Investigate: MSVC doesn't like this
 //static_assert(__cplusplus >= 201703L, "D++ Requires a C++17 compatible compiler. Please ensure that you have enabled C++17 in your compiler flags.");
 
-#ifdef DPP_BUILD
+#ifndef DPP_STATIC
 
-	#ifdef _WIN32
-		#include <dpp/win32_safe_warnings.h>
-	#endif
+	#ifdef DPP_BUILD
+
+		#ifdef _WIN32
+			#include <dpp/win32_safe_warnings.h>
+		#endif
 
-	#ifdef _WIN32
-		#define DPP_EXPORT __declspec(dllexport)
+		#ifdef _WIN32
+			#define DPP_EXPORT __declspec(dllexport)
+		#else
+			#define DPP_EXPORT
+		#endif
 	#else
-		#define DPP_EXPORT
+		#ifdef _WIN32
+			#define DPP_EXPORT __declspec(dllimport)
+		#else
+			#define DPP_EXPORT
+		#endif
 	#endif
+
 #else
-	#ifdef _WIN32
-		#define DPP_EXPORT __declspec(dllimport)
-		/* This is required otherwise fmt::format requires additional file linkage to your project */
-		#define FMT_HEADER_ONLY
-	#else
-		#define DPP_EXPORT
-	#endif
+	#define DPP_EXPORT
 #endif
 
 #ifndef _WIN32

with this diff applied does dpp still build ok outside of xmake?
the FMT_HEADER_ONLY was there for a reason and otherwise it would build but fail at runtime...

[SirLynix]

with this diff applied does dpp still build ok outside of xmake?

Yes, but DPP_STATIC should be handled in the cmakelists.

the FMT_HEADER_ONLY was there for a reason and otherwise it would build but fail at runtime...

It makes little sense to build the lib without FMT_HEADER_ONLY and use it with user code, the reason it was failing was because fmt has to be linked to the final executable without that flag, something a proper package manager guarantees.

[braindigitalis]

xmake can be instructed to use a specific version of nlohmann/fmt. The main issue here is that by embedding a specific version of those libraries (and not putting them in a namespace), you conflict with the user nlohmann/fmt libs (obligating them to use the very same version you're using for API/ABI compatibility).

Since these libraries are very well tested, I think it would be better to not embed them to prevent such issues.

I see, I will consider moving dpp's copies to a namespace to prevent conflicts.

[braindigitalis]

with this diff applied does dpp still build ok outside of xmake?

Yes, but DPP_STATIC should be handled in the cmakelists.

the FMT_HEADER_ONLY was there for a reason and otherwise it would build but fail at runtime...

It makes little sense to build the lib without FMT_HEADER_ONLY and use it with user code, the reason it was failing was because fmt has to be linked to the final executable without that flag, something a proper package manager guarantees.

thanks! can you please submit a pr of this diff against dev branch and I'll merge it in...

[SirLynix]

I see, I will consider moving dpp's copies to a namespace to prevent conflicts.

Unfortunately this won't be enough, because of preprocessor defines (libs header guards), there's no proper way to embed fmt/nlohmann in a project headers.

thanks! can you please submit a pr of this diff against dev branch and I'll merge it in...

Someone else is working on this already, all my changes will only be applied when installing dpp through xmake.

If you wish to keep using CMake, xrepo-cmake may help you to handle dependencies in a better way.

[M-U-X]

Vcpkg support would be quite nice, is it coming anytime soon?

[braindigitalis]

there's an open pr over there, ive not had time to work on it though...

[braindigitalis]

Vcpkg support would be quite nice, is it coming anytime soon?

there is now a finalized pr in vcpkg thanks to @RealTimeChris - we should be in vcpkg very soon!

[egorpugin]

fyi
Added to SW https://software-network.org/org.sw.demo.brainboxdotcc.dpp-10.0.15