Meeting: 3rdparty and nightlies

[L. E. Segovia]

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.

> 
> 
>     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
.

>  
> 
> 
>     >
>     >     - 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

-- 
amyspark 🌸 https://www.amyspark.me