[packaging] SFML build2 packages

[Fabian Meyer]

Just noticed: I meant publish to https://queue.stage.build2.org/ ;)

On 5/5/22 22:11, Fabian Meyer wrote:
> 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.
>>
>