[packaging] SFML build2 packages

[Fabian Meyer]

Hi Boris,

thanks! You were right I was using the wrong relative path to include my 
common build logic, it was just that simple!
I also moved the repository to build2-packaging.

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.
Similar thing would be with e.g. OpenMP, which needs specific compiler 
and linker flags depending on platform and compiler.
I was just wondering if there are any mechanisms available to tackle 
such kind of issues or if something is planned.

Regards
Fabian

On 4/27/22 12:19, Boris Kolpackov wrote:
> Fabian Meyer via packaging <packaging at build2.org> writes:
>
>> I am currently working on creating build2 packages for the SFML library:
>> https://github.com/Rookfighter/sfml. Currently the packages work for
>> Ubuntu and I'll be working on MacOS and Windows asap.
> Great! FYI, there is some (very) initial work on SDL (see the wip branch):
>
> https://github.com/build2-packaging/SDL2
>
> (Note that this branch attempts to use Kconfig which I am not sure is
> worth the complexity, in fact, most likely not.)
>
>
>> First off is there a way I can share code between different root.build files
>> (so different build2 packages) in the same it repo? I was thinking about
>> creating a file with common logic in the repo root, symlink it into my
>> projects and include / source the files then in the root.build files.
> Yes, that sounds like the most straightforward approach.
>
>
>> However, that did not work, build2 refuses to include or source the file
>> (can I even use include / source in a root.build?). Is my approach basically
>> the right way? I mean, it could be that I am just doing something wrong when
>> calling "include".
> I would use source. I just tried it and it seems to work for me:
>
> cd liba
> ln -s ../../sfml-common.build build/
>
> Then in build/root.build:
>
> source build/sfml-common.build
>
> The one non-obvious aspect here is that source/include is relative to
> the current scope, not current file. This is the same for buildfiles
> but not for root.build which is loaded in the root scope, thus it's
> build/sfml-common.build rather than just sfml-common.build.
>
>
>> Next is there a built-in way to detect system dependencies (like opengl) in
>> build2? I'm not sure if specifying that stuff for each target system is
>> really the right way.
> I am not sure what you mean by "detect" here. If you mean detect whether
> it is present (e.g., by trying to compile/link some test), then we try not
> to do things like this since they are very brittle. But see the autoconf
> module for an alternative approach:
>
> https://github.com/build2/libbuild2-autoconf/
>
> If by detect you mean to get the library name to import on each platform,
> then yes, specifying an appropriate platform-specific name for each target
> is the way to go, at least for now. Here are some packages that I think
> could be doing something similar:
>
> https://github.com/build2-packaging/glfw
>
> https://github.com/build2-packaging/glbinding
>
>
>> Is there any interest to move the package repository to the build2-packaging
>> organization? I would happily move it there.
> Yes, in fact we prefer it. I've sent you the invite.
>
>
>> However, I won't be able to build the audio package of sfml yet, because too
>> many dependencies are missing (libogg, openal-soft, libflac, minimp3,
>> libvorbis).
> I think that's perfectly fine: cover what you need and others have an
> option to step in and help if they need audio.