[bug#50054] gnu: Add bgfx

* gnu/packages/graphics.scm (bgfx): New variable
---
 gnu/packages/graphics.scm | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

+      (license (list license:expat license:cc0)))))

Hi,

Am Samstag, den 14.08.2021, 01:35 -0700 schrieb Andy Tai:
> * gnu/packages/graphics.scm (bgfx): New variable
> ---
>  gnu/packages/graphics.scm | 38
> ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/gnu/packages/graphics.scm b/gnu/packages/graphics.scm
> index 38feb27c87..53ac12f731 100644
> --- a/gnu/packages/graphics.scm
> +++ b/gnu/packages/graphics.scm
> @@ -2000,3 +2000,41 @@ Some feature highlights:
>  such as VR and AR on mobile, PC/desktop, and any other device.
> Monado aims to be
>  a complete and conforming implementation of the OpenXR API made by
> Khronos.")
>      (license license:boost1.0)))
> +
> +(define-public bgfx
> +  (let ((commit "65513d08541ab1ead814f2c97d0502c8d13eae68")
> +        (revision "0"))
> +    (package
> +      (name "bgfx")
> +      (version
> +       (git-version "0" revision commit))
> +      (source
> +       (origin
> +         (method git-fetch)
> +         (uri
> +          (git-reference
> +           (url "https://github.com/bkaradzic/bgfx.cmake")
> +           (commit commit)
> +           ;; Fetch git submodules
> +           (recursive? #t)))
The use of submodules is discouraged because it's often hard to reason
about them.  This is such a case.  bgfx and the other submodules each
vendor a bunch of dependencies on top of the binaries that e.g. bx
ships as part of their tools repo.  
> +         (file-name (git-file-name name version))
> +         (sha256
> +          (base32
> +           "1k18230zw3v2l0vgz5xi0l23fa0686yx0jd6hkvvvwp3zlakqp7n")))
> )
> +      (build-system cmake-build-system)
> +      (arguments
> +       `(#:tests? #f)) ;; no tests
> +      (inputs
> +       `(("glslang" ,glslang)
> +         ("libxcb" ,libxcb)
> +         ("opengl" ,mesa)
> +         ("vulkan-loader" ,vulkan-loader)))
> +      (native-inputs
> +       `(("pkg-config" ,pkg-config)
> +         ("vulkan-headers" ,vulkan-headers)))
> +      (home-page "https://github.com/bkaradzic/bgfx")
> +      (synopsis  "Cross-platform, graphics API agnostic. rendering
> library")
A dot too much :)
> +      (description "bgfx is a cross-platform, graphics API agnostic,
> +'Bring Your Own Engine/Framework' style rendering library supporting
> Direct3D,
> +OpenGL, Metal, Vulkan and WebGL.")
> +      (license (list license:expat license:cc0)))))

Question: then how in the package definition can I check out
submpodule repos and make them in the same relative positions for the
build to work?

On Sat, Aug 14, 2021 at 2:43 AM Leo Prikler
<leo.prikler@student.tugraz.at> wrote:
>
> Hi,
>
> Am Samstag, den 14.08.2021, 01:35 -0700 schrieb Andy Tai:
> > * gnu/packages/graphics.scm (bgfx): New variable
> > ---
> >  gnu/packages/graphics.scm | 38
> > ++++++++++++++++++++++++++++++++++++++
...
> > +         (method git-fetch)
> > +         (uri
> > +          (git-reference
> > +           (url "https://github.com/bkaradzic/bgfx.cmake")
> > +           (commit commit)
> > +           ;; Fetch git submodules
> > +           (recursive? #t)))
> The use of submodules is discouraged because it's often hard to reason
> about them.  This is such a case.  bgfx and the other submodules each
> vendor a bunch of dependencies on top of the binaries that e.g. bx
> ships as part of their tools repo.
> > +         (file-name (git-file-name name version))
> > +         (sha256
> > +          (base32
> > +           "1k18230zw3v2l0vgz5xi0l23fa0686yx0jd6hkvvvwp3zlakqp7n")))
> > )
> > +
>

Or your intent is that each repo should be a separate package in guix,
like bgfx with its three git repos shall be three packages in guix?

On Sat, Aug 14, 2021 at 11:07 AM Andy Tai <lichengtai@gmail.com> wrote:
>
> Question: then how in the package definition can I check out
> submpodule repos and make them in the same relative positions for the
> build to work?
>
> On Sat, Aug 14, 2021 at 2:43 AM Leo Prikler
> <leo.prikler@student.tugraz.at> wrote:
> >
> > Hi,
> >
> > Am Samstag, den 14.08.2021, 01:35 -0700 schrieb Andy Tai:
> > > * gnu/packages/graphics.scm (bgfx): New variable
> > > ---
> > >  gnu/packages/graphics.scm | 38
> > > ++++++++++++++++++++++++++++++++++++++
> ...
> > > +         (method git-fetch)
> > > +         (uri
> > > +          (git-reference
> > > +           (url "https://github.com/bkaradzic/bgfx.cmake")
> > > +           (commit commit)
> > > +           ;; Fetch git submodules
> > > +           (recursive? #t)))
> > The use of submodules is discouraged because it's often hard to reason
> > about them.  This is such a case.  bgfx and the other submodules each
> > vendor a bunch of dependencies on top of the binaries that e.g. bx
> > ships as part of their tools repo.
> > > +         (file-name (git-file-name name version))
> > > +         (sha256
> > > +          (base32
> > > +           "1k18230zw3v2l0vgz5xi0l23fa0686yx0jd6hkvvvwp3zlakqp7n")))
> > > )
> > > +
> >
>
>
> --
> Andy Tai, atai@atai.org
> Year 2021 民國110年
> 自動的精神力是信仰與覺悟
> 自動的行為力是勞動與技能

If possible, we should have one package per repo with everything nasty
in that repo removed.  I realize that's a lot more to ask for than
simply "a package that builds", but we do have some standards.

Optionally, if it's really not possible, you can still go for various
merged origins, but I should stress that in that case you also ought to
filter out the nasty stuff.  It's usually easier to do that if you have
one package for whatever you could reason to be a package upstream.

Am Samstag, den 14.08.2021, 11:24 -0700 schrieb Andy Tai:
> Or your intent is that each repo should be a separate package in
> guix,
> like bgfx with its three git repos shall be three packages in guix?
> 
> On Sat, Aug 14, 2021 at 11:07 AM Andy Tai <lichengtai@gmail.com>
> wrote:
> > Question: then how in the package definition can I check out
> > submpodule repos and make them in the same relative positions for
> > the
> > build to work?
> > 
> > On Sat, Aug 14, 2021 at 2:43 AM Leo Prikler
> > <leo.prikler@student.tugraz.at> wrote:
> > > Hi,
> > > 
> > > Am Samstag, den 14.08.2021, 01:35 -0700 schrieb Andy Tai:
> > > > * gnu/packages/graphics.scm (bgfx): New variable
> > > > ---
> > > >  gnu/packages/graphics.scm | 38
> > > > ++++++++++++++++++++++++++++++++++++++
> > ...
> > > > +         (method git-fetch)
> > > > +         (uri
> > > > +          (git-reference
> > > > +           (url "https://github.com/bkaradzic/bgfx.cmake")
> > > > +           (commit commit)
> > > > +           ;; Fetch git submodules
> > > > +           (recursive? #t)))
> > > The use of submodules is discouraged because it's often hard to
> > > reason
> > > about them.  This is such a case.  bgfx and the other submodules
> > > each
> > > vendor a bunch of dependencies on top of the binaries that e.g.
> > > bx
> > > ships as part of their tools repo.
> > > > +         (file-name (git-file-name name version))
> > > > +         (sha256
> > > > +          (base32
> > > > +           "1k18230zw3v2l0vgz5xi0l23fa0686yx0jd6hkvvvwp3zlakqp
> > > > 7n")))
> > > > )
> > > > +
> > 
> > --
> > Andy Tai, atai@atai.org
> > Year 2021 民國110年
> > 自動的精神力是信仰與覺悟
> > 自動的行為力是勞動與技能
> 
>

Leo, by "nasty stuff" you meant non-free stuff (I doubt if there is
any in a graphics library but will check), or you meant the embedded
packages that shall be reference to other packages in guix (if
packaged already)?   I think the embedded copies of other stuff may
have local customization that may make it impossible to simply build
with the existing packages in guix.

On Sat, Aug 14, 2021 at 11:48 AM Leo Prikler
<leo.prikler@student.tugraz.at> wrote:
>
> If possible, we should have one package per repo with everything nasty
> in that repo removed.  I realize that's a lot more to ask for than
> simply "a package that builds", but we do have some standards.
>
> Optionally, if it's really not possible, you can still go for various
> merged origins, but I should stress that in that case you also ought to
> filter out the nasty stuff.  It's usually easier to do that if you have
> one package for whatever you could reason to be a package upstream.

Hi,

Am Montag, den 16.08.2021, 05:42 -0700 schrieb Andy Tai:
> Leo, by "nasty stuff" you meant non-free stuff (I doubt if there is
> any in a graphics library but will check), or you meant the embedded
> packages that shall be reference to other packages in guix (if
> packaged already)?   I think the embedded copies of other stuff may
> have local customization that may make it impossible to simply build
> with the existing packages in guix.
Nasty stuff are not only already existing packages, but also outdated
versions thereof.  If there are heavily customized versions or packages
not yet included in Guix, then those can be left in (but with a
remark!), though in the long term it would be better to make those
packages work with upstream versions rather than require specific
tweaking.

The other thing I already mentioned are binaries, which upstream seems
also aware about, see e.g. 
https://github.com/bkaradzic/bgfx/commit/caed3f91026bf0e703f1eaf6f622e27b820df86c

Regards

The following bug should be a prerequisite of this bug

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50229
adding build tool genie to guix as a package

On 2021-08-27 19:49, Andy Tai wrote:
> The following bug should be a prerequisite of this bug
> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50229
> adding build tool genie to guix as a package

Done:

   To: Control server <https://debbugs.gnu.org/server-control.html>

   block 50054 by 50229

Kind regards,

T (it's aliiive) G-R

Sent from a Web browser.  Excuse or enjoy my brevity.