guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#50054] [PATCH] gnu: Add bgfx


From: Leo Prikler
Subject: [bug#50054] [PATCH] gnu: Add bgfx
Date: Sun, 29 Aug 2021 22:04:06 +0200
User-agent: Evolution 3.34.2

Hi

Am Sonntag, den 29.08.2021, 11:21 -0700 schrieb Andy Tai:
> > First things first, this still does a build of everything at once
> > rather than one package per repo.  Have you looked into the one
> > package
> > per repo thing and decided that it's not possible or do you simply
> > continue with the package as-is because it builds?
> > 
> 
> Hi, the author of the upstream is very opinionated; this is how how
> arranges the things for this package and his documentation on how to
> build mentions checking out all three repos and build them together.
I wouldn't read too much into that.  Just because they put those
directories next to each other doesn't mean Guix is forced to do the
same.  Many people have their shells in /bin/bash.  Some use
/usr/bin/bash.  Neither exists in Guix and we still manage to somehow
ship bash.

Plus, according to upstream, the CMake structure is literally an
alternative build system and there are several versions of it,
suggesting that it shouldn't be particularly hard to adapt bgfx to
something else. 

> I can look into his build system setup to try to build each repo
> separately but that means I  need to maintain custom build inside the
> package and normally I don't think distribution package maintainers
> want to  go into inside the package to setup alternative build
> processes separate from upstream--what goes inside the package is
> best left to the author.  If you maintain essentially separate build
> scripts in the original package in terms of cmake or genie, that is
> outside the scope of guix and hard to maintain as you need to keep up
> with new releases.
People have rolled their own Makefiles for decades and Guix has a way
of coping with that.  You simply need to delete bootstrap and configure
from gnu-build-system or replace them with whatever command upstream
uses.  

> > Even if you want to do a merged build, binaries, vendored
> > dependencies,
> > etc. ought to be removed in the origins, not at build time.  I
> > suggest
> > you use a computed origin to merge the three and remove all those
> > things.
> > 
> 
> Is there a "computed origin" example in existing package receipts in
> guix?
There are few examples, as computed origins are typically only used
with huge pieces of software that need large patches to throw away
proprietary blobs.  See the linux kernel or chromium.

Regards






reply via email to

[Prev in Thread] Current Thread [Next in Thread]