Incorrect namespace.

[egorpugin]

https://github.com/brainboxdotcc/DPP/blob/master/mlspp/include/namespace.h#L4

[braindigitalis]

this definition is not used anywhere though and is part of a third party dependency. If you try to change it, it will be overwritten by some voodoo in its cmakelists.txt.

[Mishura4]

... What's the issue here, what issue are you running into?

[egorpugin]

Building the library using custom build. So, there is no cmake and this is obviously an error.

[egorpugin]

Also seeing some other error (upgrading from 10.0.30)

src/dpp/voice/enabled/courier_loop.cpp
DPP-10.0.35/src/dpp/voice/enabled/courier_loop.cpp(233): error C2839: invalid return type 'int *' for overloaded 'operator ->'
DPP-10.0.35/src/dpp/voice/enabled/courier_loop.cpp(233): error C2039: 'decryptors': is not a member of 'std::unique_ptr<int,std::default_delete<int>>'
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\include\memory(3335): note: see declaration of 'std::unique_ptr<int,std::default_delete<int>>'
DPP-10.0.35/src/dpp/voice/enabled/courier_loop.cpp(235): error C3536: 'decryptor': cannot be used before it is initialized
DPP-10.0.35/src/dpp/voice/enabled/courier_loop.cpp(235): error C2839: invalid return type 'int *' for overloaded 'operator ->'
DPP-10.0.35/src/dpp/voice/enabled/courier_loop.cpp(235): error C2039: 'decryptors': is not a member of 'std::unique_ptr<int,std::default_delete<int>>'
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\include\memory(3335): note: see declaration of 'std::unique_ptr<int,std::default_delete<int>>'

[Mishura4]

What "custom build"?

[egorpugin]

Using sw tool https://software-network.org/org.sw.demo.brainboxdotcc.dpp/specification

This is an updated spec for 10.0.35 (not working atm)

void build(Solution &s)
{
    auto &t = s.addTarget<LibraryTarget>("brainboxdotcc.dpp", "10.0.35");
    t += Git("https://github.com/brainboxdotcc/DPP", "v{v}");

    t += cpp20;
    t += "include/dpp/.*"_rr;
    t += "src/dpp/.*"_rr;
    t.Public += sw::Static, "DPP_STATIC"_def;
    t += "DPP_BUILD"_def;
    t.Public += "include"_idir;
    //t += "include/dpp"_idir;
    t += "org.sw.demo.madler.zlib"_dep;
    t += "org.sw.demo.openssl.ssl"_dep;
    t += "org.sw.demo.xiph.opus"_dep;
    t += "org.sw.demo.cisco.mlspp-master"_dep;
    t.Public += "DPP_USE_EXTERNAL_JSON"_def;
    t.Public += "org.sw.demo.nlohmann.json.natvis"_dep;
    if (t.getCompilerType() == CompilerType::MSVC)
        t.CompileOptions.push_back("/bigobj");
    //t.pushBackToFileOnce("include/dpp/nlohmann/json_fwd.hpp", "#include \"json.hpp\"");

    t += "mlspp/include/.*"_rr;
    t += "mlspp/src/.*"_rr;
    t += "mlspp/lib/bytes/.*"_rr;
    t += "mlspp/lib/tls_syntax/.*"_rr;
    t += "mlspp/lib/hpke/.*"_rr;

    t.Public += "include"_idir;
    t += "mlspp/include"_idir;
    t += "mlspp/lib/bytes/include"_idir;
    t += "mlspp/lib/tls_syntax/include"_idir;
    t += "mlspp/lib/hpke/include"_idir;
}

[braindigitalis]

t += "org.sw.demo.cisco.mlspp-master"_dep;

Please do not do this. It is not a standard build of mlspp and can't be imported this way. we and discord have customised the mlspp we use with some subtle changes, and integrated it into the dpp build system.

That said i am not entirely sure what this build system is doing.

mlspp and its dependencies must be statically linked into dpp from the custom builds (which do not install separate shared objects) and everything else may be statically or dynamically linked at your discretion.

[egorpugin]

Yes, was a leftover. I've added DPP's local mlspp files to the build below in that code block. No luck atm, but I'll try to figure it out.

But the issue itself is about not leaving source code files in incorrect state.

[Mishura4]

It seems you're trying to build DPP statically as well, which is simply something we don't support on Windows.

[egorpugin]

Why is it so?

Any software can be built statically. I use DPP only statically linked on all major platforms.

[braindigitalis]

Static builds will bundle other stuff like static openssl, this is a security risk as it cant be upgraded with the operating system's openssl version or the package manager's without a rebuild of the program.

Also, because in our experience 90% of people who ask for this, are wanting to embed it in some kind of malicious program and are unable to figure it out themselves. We don't support it, it is possible with the right setup (but not tested) but our default configuration is always dynamic build.

As such the default should be dynamic. It is 100% supported on all platforms we build on.