Crafft: source and binary variants for the "same" blueprint

[Hannah von Reth]

Hi,

How about two seperate blueprints.
A src one in libs/_linux and one in binary/_win
Yes that requires also a if in all blueprints using r but I guess it would be the most clean?

Cheers,

Hannah


________________________________
From: Kde-windows on behalf of Thomas Friedrichsmeier
Sent: Thursday, June 16, 2022 11:30
To: kde-windows at kde.org
Subject: Crafft: source and binary variants for the "same" blueprint

Hi!

I'm wondering how to deal best with a situation where a blueprint
should be built from source on some platforms, but installed from
upstream binaries on others.

Sepcifically, I'm talking about RKWard. Our dependency R needs to use
upstream binaries on Mac and Windows(*), but, obviously, can only be
built from source on Linux (for AppImage).

I can think of three different approaches:

1) Provide a single blueprint that, however, will do quite different
things on the different platforms.
2) Provide a single blueprint "name", but in separate platform specific
variants, each in a _windows, _mac, or _linux folder.
3) Provide two separate blueprints "r-binary", and "r-source", which
each may not be available for all platforms. The depending blueprint
(i.e. rkward in this case) will have a platform-specific "if" to depend
on the most appropriate variant.

1) is probably going to make for a rather messy blueprint file. 2)
seems cleaner, but may still be somewhat non-obvious. 3) looks like a
clean an very flexible solution. However, it could create conflicts
between "r-binary" and "r-source", in case both are available on a
platform.

So which one to use?

This is also my question behind
https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/405
(perhaps I should have asked, here, in the first place).

Thanks!
Thomas

----

(*) Quick summary of the background: For one thing building R is
somewhat difficult, because a fortran compiler is needed. More
importantly, however, we need to support (thousands of) upstream
provided add-on packages, which, for Mac and Windows, are provided as
binaries, again.

This will not work, reliably, with a custom compiled R. On Windows it's
ABI details that will break our neck. On Mac it's the assumption of
fixed absolute paths under /Library/Frameworks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20220616/5f2fb065/attachment.htm>