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
