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