Meeting: 3rdparty and nightlies

[Ben Cooksley]

On Fri, Jan 27, 2023 at 1:13 AM L. E. Segovia <amy at amyspark.me> wrote:

> Hi!
>
> On 25/01/2023 15:14, Ben Cooksley wrote:
> >
> >     Going to research this more, but using DESTDIR/INSTALL_PATH feels
> like
> >     an Autotoolism-- in any case, it should give at least problems when
> >     relocating dependencies e.g. with pkg-config .pc files. (I may have
> >     already seen such a problem with the Python 3.10 build last night, am
> >     awaiting confirmation.)
> >
> >
> > Whilst it may seem like an "Autotoolism" it is very much fully supported
> > by CMake (and likely other build systems)
> > Note that this is an environment variable, not something you pass as a
> > configuration argument, and it only should be present when running "make
> > install" not during any other part of the build process.
> >
> > I'd be very surprised if Python did not properly support
> > DESTDIR/INSTALL_ROOT.
>
> Python 3.10 started hardcoding it, which bit me and Iván just last week
> and was fixed yesterday.
>

In general I'd say you can assume that those two variables will be well
supported as Linux distributions pretty much require it as part of their
packaging processes.
It's a bit surprising that Python broke that.


>
> >
> >
> >     What I had in mind was one of:
> >
> >     - the ASWF's overlaid Docker images, where each artifact image calls
> >     upon the images of its dependencies
> >     - Homebrew's usage of Docker scratch containers to store the artifact
> >     contents
> >
> >
> > Docker is not available for native use on macOS to my knowledge, which
> > creates a bit of a problem there no?
>
> You can still use Docker commands (or your favourite OCI container
> registry API itself) to fetch and push "images" (which would be in fact
> just the tarballed 3rdparty output with some extra metadata). For an
> example, I just found how Homebrew started doing it:
>
> https://github.com/Homebrew/brew/blob/master/Library/Homebrew/github_packages.rb


Interesting approach they have there. In their case it works a bit better
as they're handling Homebrew Bottles, which is a complete set of
dependencies and the application itself.

In the case of Krita you'd want to be able to update lower level
dependencies with patches / bugfix releases without having to rebuild the
stack though.
Not sure that relying on OCI format images will allow that as higher layers
are bound to the layer below them (so you can't just "swap them out") and
it won't solve the issue of capturing just the things added by installing
an additional dependency either without some custom logic (which is
required either way)

>From an infrastructure perspective i'm quite reluctant to deploy Gitlab
Image Registry as there isn't much reason to do so as our projects don't
really have a use for it so it would be for Krita only.
The package registry meanwhile works without needing anything additional.


> .
>
> >
> >
> >
> >     >
> >     >     - Whether Docker or not, is Sysadmin making available the
> >     container
> >     >     registry feature of Gitlab?
> >     >
> >     >
> >     > There are no plans to make the Container Registry feature of Gitlab
> >     > available, as we have a namespace on Dockerhub which hosts our
> images.
> >     >
> >     > If you are thinking of creating custom images, i'd first advise you
> >     > first to strongly consider using the centrally maintained/updated
> >     images.
> >     > If they are actually completely unsuitable then submit a MR to add
> the
> >     > appropriate image there.
> >     >
> >     > For Linux the centos7-craft image is the image used to build all
> our
> >     > other appimages, so please don't reinvent the wheel there.
> >     >
> >     > For Windows you likely will need to create a custom image due to
> >     Krita's
> >     > use of MIngW-LLVM and Strawberry Perl among other things. Given you
> >     > still need at least part of the Windows SDK, please use
> >     windows-msvc2019
> >     > as your base (which also includes Python and Git) - the Windows SDK
> >     > components are a real mission to get installed reliably in Docker
> >     which
> >     > took more than a few goes to get working and I don't fancy looking
> >     after
> >     > that in more than one place.
> >
> >     I do not think we need extra base images (see above re: homebrew).
> But
> >     you're right in that we will need at least to customize the
> compiler. We
> >     can already deploy Strawberry Perl if missing.
> >
> >
> > If something changes infrequently then it makes more sense to have it
> > burned into the image.
> > Ensures that things run faster and use less resources for one.
> >
>
> Just checked; LLVM-MinGW is deployed manually on a local developer
> environment, and Strawberry Perl is already skipped if a valid Perl is
> detected in the system. We can bake these in the image, no action is
> needed in 3rdparty.
>
> Cheers,
>
> amyspark
>

Cheers,
Ben


>
> --
> amyspark 🌸 https://www.amyspark.me
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20230128/ba6337c5/attachment.htm>