export PYTHON_CONFIGURE_OPTS="--enable-shared"
export PYENV_PYTHON_VERSION=3.10.0
$PYENV install -v $PYENV_PYTHON_VERSION
PIP="$PYENV_ROOT/shims/pip"
$PYENV local 3.10.0
$PIP install --upgrade --user pip
— snip —
The use of "pyenv local 3.10.0†creates the ~/.pythonversion file - but using the *cough* correct pip3, there’s no need for a pipenv before pip3 … so no .pythonversion :-)
I did a clean run with your latest pushed changes and confirm that the setup script now works.
These problems are just like Pascal’s problems with "ft-fb.h not found†last month - but I did make some progress.
The key issue is that the freetype builds, despite being run in an environment where no environment variables contain the word “homebrewâ€, still decides to find the librotlidec library in /opt/homebrew/lib. This causes a build failure later on ...
Adding "-D CMAKE_DISABLE_FIND_PACKAGE_BrotliDec=TRUE†to both steps in GtkApplication-osx.modules resolves this issue.
This looks like a bug on freetype's part - they should not be scanning random parts of the filesystem ! Anyhow, when disabling the search for this library, and re-running, I end up with all steps of the instructions on the webpage working.
Perhaps you want to make a change GTK-OSX.modules, perhaps not. The big thing here is that developers should not have to have a separate username, vm or machine to build GtkApplication apps - especially when some simple configuration can resolve these issues. Simply put for many, the tools that macports or homebrew provide are required part of daily workflows. Maybe putting a catch at the start of gtk-osx-setup.sh would be useful? Something like:
—snip--
CHECK_HOMEBREW=`printenv |grep homebrew`
If [[ Z$CHECK_HOMEBREW == “Z†]] ; then
echo “Can’t use this script with a homebrew environment !â€
exit 1
fi
— snip --
I’ll get around to trying to build the simple app that I started out on two weeks ago - and will report back if this ends up being problematic.
Thanks for your help meanwhile.
Regards
Paul
Ah, got it. Fix pushed. Thanks.
I also finally figured out the cause of "pyenv: pip: command not found" and pushed a fix for that too.
BTW, I don't see ~/.pythonversion. Are you sure that's from pyenv?
Regards,
John Ralls
On Feb 15, 2022, at 2:08 PM, Spock <spock rogersfamily me uk> wrote:
Sorry - I did not explain myself well enough there John.
I guess the issue that I’m pointing out is that gtk-osx-setup.sh writes the jhbuild script but writes an absolute path for $PATH to be set to rather than escaping so that $PATH is read from the environment when running jhbuild.
In the code snip from gtk-osx-setup.sh below the second $PATH should be escaped to be ‘\$PATH’ (as shown). Without this, it means that PATH only gets set correctly if the environment $PATH when calling gtk-osx-setup.sh contains something like “~/.new_local/binâ€.
— snip ---
cat <<EOF > “$DEVPREFIX/bin/jhbuild"
#!$DEVPREFIX/bin/bash
...
export PATH="$PYENV_ROOT/shims:$PATH†<<<<<<<- Should be …/shims:\$PATH
...
exec $DEVPREFIX/bin/pipenv run jhbuild \$@
EOF
— snip ---
This explains why people with fresh machines or fresh usernames end up with the build failing.
So the either the instructions need to say “Set your PATH to include ~/.new_local/bin before invoking gtk-osx-setup.sh†or the script needs to be fixed to include the line:
—snip—
export PATH="$PYENV_ROOT/shims:$PATHâ€
—snip --
Once I make this change, I can build a lot more of the "jhbuild build meta-gtk-osx-bootstrap meta-gtk-osx-gtk3“ stage.
It still fails, btw, but I need to diagnose why and or ask some more questions!
Hope this makes sense and is helpful?
Regards
Paul
On 15 Feb 2022, at 18:52, john <jralls ceridwen us> wrote:
Well, it's been a requirement since forever that you put $DEVPREFIX/bin in your path before invoking jhbuild, but I suppose there's no harm in also adding it with jhbuild to prevent path pollution. I hadn't noticed ~/.pythonversion. That's rude of them, I'll look for a way to bury that somewhere so that it doesn't affect other stuff.
Regards,
John Ralls
On Feb 15, 2022, at 5:26 AM, Spock <spock rogersfamily me uk> wrote:
Hi John,
I guess the issue with the $PYENV local 23.10.0 is that it causes ~/.pythonversion to be created - which may or may not be a permanent change a developer might want?
The more serious issue is with meson not finding ninja. I think this is down to jhbuild not having ~/.new_local/bin in its path.
Here’s an example:
— snip —
j@pauls-mbp ~ [nobrew] % echo $PATH
/Users/j/.new_local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/Users/j/.cargo/bin
j@pauls-mbp ~ [nobrew] % jhbuild shell
Loading .env environment variables...
Found Command Line Tools 'version: 13.2.0.0.1.1638488800'
Command Line Tools version 13.200000
Prefix: /Users/j/gtk/inst
Entered jhbuild shell, type 'exit' to return.
j@pauls-mbp ~ % jhbuild
zsh: command not found: jhbuild
j@pauls-mbp ~ %
— snip —
I think this means that the jhbuild configuration installed by gtk-osx-setup.sh does not set up jhbuild so that it uses the binaries that have been installed?
I’m not sure if the issue is with jhbuild or gtk-osx-setup.sh - but I guess it’s right to start in this list before looking at what might be wrong (if anything) with jhbuild?
Regards
Paul Rogers
On 15 Feb 2022, at 01:55, John Ralls <jralls ceridwen us> wrote:
On Feb 14, 2022, at 10:03 AM, Spock <spock rogersfamily me uk> wrote:
Hi, I’m running gtk-osx-setup.sh on an M1 Mac/MacOS 12.2 and am having a couple of problems ...
First off, I’m running without any homebrew paths in any of the environment variables.
Now, with this shell, when I run the script, I get the following:
— snip ----
pyenv: pip: command not found
The `pip' command exists in these Python versions:
3.10.0
Note: See 'pyenv help global' for tips on allowing both
python2 and python3 to be found.
pyenv: pip: command not found
The `pip' command exists in these Python versions:
3.10.0
Note: See 'pyenv help global' for tips on allowing both
python2 and python3 to be found.
—- snip ---
So I add a line to the script to allow it to find python:
— snip —
PIP=“$PYENV_ROOT/shims/pipâ€
# Point pyenv at the 3.10.0 Python ...
$PYENV local 3.10.0
$PIP install --upgrade --user pip
— snip ---
With this line, I remove the artefacts from the previous build and re-run. This time the script completes, so I move on to “./.new_local/bin/jhbuild bootstrap-gtk-osx which appears to complete successfully.
*** Was this the right thing to do?
The final step “jhbuild meta-gtk-osx-bootstrap meta-gtk-osx-gtk3 fails due to problems finding a version of ninja …
— snip ---
gtk-doc 1.33.1
User defined options
libdir : lib
prefix : /Users/j/gtk/inst
wrap_mode : nofallback
tests : false
yelp_manual: false
ERROR: Could not detect Ninja v1.8.2 or newer
— snip ---
I checked the version installed by the script …
— snip ---
j@pauls-mbp ~ [nobrew] % ./.new_local/bin/ninja —version
1.10.2
— snip ---
*** So what is happening with ninja? Is there a setup step I’m missing?
Any help much appreciated!
Your fix for pip seems reasonable. Did you remember to add ~/.new_local/bin to $PATH?
Regards,
John Ralls