[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