Re: pre-built quartz variant packages

[Joshua Root]

On 17/1/2024 05:42, Valerio Messina via macports-dev wrote:
Using the pre-built gtk3 from macport (and osxcross), saved me the 
library built time just for test of my apps, and the requirement to 
access macOS on every run.
Then I discovered to start the app I had to install Xquartz on the real 
hw, and this is not a thing normal user is used to do, or is able to or 
want to do.


Seems to me that native Quartz variant of gtk3 work like or better than 
Xquartz (default) variant. At least better than gtk on Win.


Really hope you can please provide the gtk3 pre-built Quartz variant


I agree that the UX surrounding the quartz/x11 choice is bad. 
Unfortunately it's harder to fix than you might hope, and gtk3 itself 
may be the easiest part of the puzzle. A number of other ports like 
glib2 and cairo are also involved, and have to support other dependents 
that may be using gtk2 or something else entirely. Many intermediate 
dependencies build differently depending on whether they are built 
against quartz or x11 variants of their dependencies, so there's a whole 
chain that has to be managed. Some ports fail to build against quartz 
dependencies.


The proposed solution to all of the above is to split everything that 
both has dependents and is affected by the quartz/x11 choice into two 
subports. Unfortunately nobody has yet implemented this.


Relevant tickets:






- Josh

Re: pre-built quartz variant packages

[Valerio Messina via macports-dev]

sorry, I have never made a native port installation.

But given the syntax I found online:
$ port install  + -
I expect a user can install every variant

If only default variant is pre-built what is shown by:
$ port variants gtk3
?

Native gtk3 building on macOS is trivial, I made that from source 
following instruction on GTK web site, and I use that for packaging of 
my applications.
Anyway this is not the macport version, it the one from gtk.org and is 
only source not pre-build.
Is trivial but require time, and again on new version, and require a 
developer access to macOS on another machine dedicated to that.


Using the pre-built gtk3 from macport (and osxcross), saved me the 
library built time just for test of my apps, and the requirement to 
access macOS on every run.
Then I discovered to start the app I had to install Xquartz on the real 
hw, and this is not a thing normal user is used to do, or is able to or 
want to do.


Seems to me that native Quartz variant of gtk3 work like or better than 
Xquartz (default) variant. At least better than gtk on Win.


Really hope you can please provide the gtk3 pre-built Quartz variant

a newby of macOS
thank you,
Valerio


On 1/14/24 5:08 PM, Sergio Had wrote:

AFAIK ports are only being pre-built with the default variant.

GTK should be trivial to build though.

>
On Jan 14, 2024 at 23:58 +0800, Valerio Messina via macports-dev 
, wrote:

I'm not sure this is the right list to ask for pre-built macports.

In case can you please direct me to the right one?

thank you,
Valerio


On 12/5/23 10:47 PM, Valerio Messina via macports-dev wrote:

hi,
as a user of osxcross, I also use the good of macports.
I read that is not your main target, but tolerate cross-built from other
OS. I'm on Debian.

I saw there are pre-built packages here:
https://packages.macports.org/
and this is where the 'osxcross-macport' get the packages.

Native macport client has support for variants with something like:
$ port variants  # show package variants
$ port install  + -   # install variant1, not variant2

I saw on packages.macports.org there are only X11 packages, and seems
native quartz variant are missing.
So for example for gtk3-devel:
https://ports.macports.org/port/gtk3-devel/details/
is available for X11 backend only as pre-built for foreign OS.

Is there a reason for this?

Having native quartz pre-built packages will help developer to target
quartz instead of xquartz, without the need to (cross)build the GTK
itself. This is so for other library with variants.

As now the bash script 'osxcross-macport' do not support variants, but
I'm sure can be easily upgraded if packages server will host quartz
variants.

thank you for explanation and work,



--
Valerio



--
Valerio

MacPorts 2.9.0-rc1 now available for testing

[Joshua Root]

Source code and pkgs for MacPorts 2.9.0-rc1 are now
available [1]. Testing of either of these install methods is helpful.

Be prepared to encounter bugs. As always, having a recent backup would
be wise. Please report any bugs that you find [2] (after first searching
Trac [3], of course!)

If no show-stopping bugs are found in the next few days, this will
become the 2.9.0 release.

There are a large number of changes in this release. See the ChangeLog
[4] for a list of most of them. You may like to focus your testing on
the new features in that list, as well as your normal usage.

Changes since beta1 are:
* Version number only.

Cheers,
Josh

[1] 
[2] 
[3] 
[4]