[packaging] SFML build2 packages

[Fabian Meyer]

Hi Boris,

SFML is now working for MacOS and Windows (msvc and clang) in GitHub 
Actions and bdep ci 
(https://ci.stage.build2.org/@c30708b9-1ee2-4c97-9cb9-6383021e89ec). 
Just as side note: I do not plan to make Android and iOS work. Should I 
also publish it to https://stage.build2.org? Are there any specific 
steps for doing so?

I also want to port a few more projects / packages for build2 since SFML 
is now close to be working :D. E.g. TGUI 
(https://github.com/texus/TGUI), which is a GUI framework building upon 
SFML (and other backends).
Do you want me to inquire you about each new port? Or should I just 
create new repos in the build2-packaging organization? Or should I first 
start with them in my own space with new repos?

Regards
Fabian

On 5/5/22 14:14, Boris Kolpackov via packaging wrote:
> Boris Kolpackov via packaging <packaging at build2.org> writes:
>
>> Fabian Meyer <fabian.meyer at posteo.de> writes:
>>
>>> Concerning "detecting" system dependencies like OpenGL: You are right
>>> "detect" is the wrong term here. I meant more something like a meta package
>>> which would figure out the linker flags depending on my platform and
>>> compiler configuration. I already had a look at the glfw package for this.
>>> The thing is, it specifies pretty much the same flags for Linux / Windows /
>>> Mac that SFML does and probably SDL will do the same. Seems like a lot of
>>> redundancy to me.
>> True, though this "redundancy" can quickly become "flexibility" if one
>> of these libraries wants to do things slightly differently. But I still
>> think it may be worth having some mechanism here.
>>
>>
>>> Similar thing would be with e.g. OpenMP, which needs specific compiler and
>>> linker flags depending on platform and compiler.
>> Hm, we could create a binless library (i.e., like a header-only library
>> but actually without any headers) whose only purpose is to export
>> dependencies on other libraries, potentially in a platform-specific
>> manner.
>>
>> Interesting idea, we can give it a try (and maybe write a HOWTO) if you
>> are willing to help flesh the approach out (I am completely ignorant of
>> all things OpenGL).
> Ok, I took a look at this in the context of the "pthread mess" and
> while in the end a metadata library for pthread is probably an
> overkill, I made one up as an example of the overall approach:
>
> https://github.com/build2-packaging/libpthread-meta
>
> So feel free to try to do something analogous for OpenGL and/or
> OpenMP and let me know how it goes. Just note that this requires
> the latest (as in, today's) staged toolchain.
>