[FR] Amalgamated build

[oviano]

It would be great if there was a python (or whatever) script that could be run to gather together all the necessary files and produce an srt.c and srt.h (and src-config.h as suggested in #2610) for trivial dropping into a project.

The script could take in the necessary parameters that control the output - such as which enclib to use (so it embeds the correct cryspr-xxxx.c), c++11 support, etc.

[ethouris]

Ok, I missed that for a long time by some reason. Currently it is expected to rely mainly on pkg-config.

What I can see here is that it's lacking the exact crypto libraries under the Libs key, but the enc libraries are present under the Requires key. I didn't check, but in case when you have a crypto library provided manually (not through pkg-config), then the generated pc file for SRT should contain these under Libs key.

I don't know how it could be done better than with pkg-config. I understand that on some systems pkg-config is not usable or not the preferred solution, but then what? The extra header file covers only the required build configuration preprocessor macros. But what about extra include directories, library directories, library names, dependent libraries etc.?

The only thing that comes to my mind is some kind of "manifest" file that would contain this kind of information, formatted in the style of Makefile or shell (none of them is really portable, but then compiler options aren't either).

In projects that use the "imported-build" SRT I'm using such a method that the library is compiled and installed in a custom directory and then treated as an external library - accessed through pkg-config. Another possibility would be to do "include" for the SRT's cmake build file, if such a thing works. Or - as srt-xtransmit project does it - add it to the project file as a subdirectory.

Actually I don't know how exacty you imagine this solution to work.

[oviano]

I admit I hadn't given proper thought to all the possible dependencies but maybe it doesn't need to resolve/care about the dependencies and this would be up to the end user.

In my scenario, I build for Android, iOS, macOS, tvOS and Windows, using ENABLE_STDCXX_SYNC=1. Other than my reliance on Botan (an amalgamation itself), there are no dependencies.

So in this case, I'd be able to run some script which would spew out srt_amalgamation.h and srt_amalgamation.cpp where the header file defines what is necessary (see what I am defining in my project, manually, below) and then it's up to me to make sure the dependencies are available (in my case, just make sure it can find <botan/botan.h> or whatever it is).

            SRT_VERSION="${SRT_VERSION}.${SRT_VERSION_MINOR}.${SRT_VERSION_PATCH}"
            SRT_ENABLE_ENCRYPTION=1
            ENABLE_AEAD_API_PREVIEW=1
            USE_BOTAN=1
            CRYSPR2=1
            ENABLE_BONDING=1
            ENABLE_STDCXX_SYNC=1
            ENABLE_LOGGING=1
            LINUX=1 (for android only)

You could in theory distribute a small set of source files with a release, tailored for say Botan, along with a botan amalgamation (or another provider if they have an amalgamation), and then someone could drop these into a project very easily.

I'm thinking aloud here, maybe what you have is enough!

[ethouris]

Actually I'm stronly in favor of pkg-config - although this mechanism has several problems especially when working with a cross-compiling environment. So, if not pkg-config, then there must be something else that provides you with similar features. But I wouldn't like to be the one to invent a new standard for this. If you can at least adjust yourself to use pkg-config, or even do something to make your project simply read the required information from there, this would be most useful.

[oviano]

Yep you only have to do a cursory search on SO to see the fun people have getting pkg-config working correctly on various platforms (esp Windows).Actually, this pkg-config angle is a bit of a rabbit-hole - all I’m suggesting really is a script where you tell it what platform and encryption lib you want and it spews out an amalgamated header and source file comprised of the appropriate files for that platform and encryption lib.How it resolves to find <mbedtls/blah.h> etc when the user compiles it is for the user to deal with in their project by setting up appropriate include directories.I realise its not a priority etc just a suggestion - no worries if you want to close this issue I won’t be upset :)On 6 Oct 2023, at 08:33, Sektor van Skijlen ***@***.***> wrote: Actually I'm stronly in favor of pkg-config - although this mechanism has several problems especially when working with a cross-compiling environment. So, if not pkg-config, then there must be something else that provides you with similar features. But I wouldn't like to be the one to invent a new standard for this. If you can at least adjust yourself to use pkg-config, or even do something to make your project simply read the required information from there, this would be most useful. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>