[packaging] SFML build2 packages

Boris Kolpackov boris at codesynthesis.com
Wed Apr 27 10:19:38 UTC 2022


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.



More information about the packaging mailing list