On .pythonversion, got it. Glad that's fixed. On brotlidec in homebrew are you *sure* that there's no link to it in /usr/local/lib? That's one of Homebrew's major malignancies, by default it links its files into the default search locations. I'm not inclined to add work-arounds for users who ignore my precondition that homebrew should not be installed. You can add the additional argument to jhbuild-custom. That file exists specifically to customize your build.
Regards, John Ralls > On Feb 16, 2022, at 2:56 AM, Spock <[email protected]> wrote: > > Happy to be of some help! > > My issue with ~/.pythonversion was due to my rough fix for the pip issue: > > —snip— > 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. > > As an aside, I found problems with the later steps of the instructions on > https://wiki.gnome.org/Projects/GTK/OSX/Building > <https://wiki.gnome.org/Projects/GTK/OSX/Building> ... > > 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 > > >> On 16 Feb 2022, at 05:30, John Ralls <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> 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 <[email protected] >>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Feb 14, 2022, at 10:03 AM, Spock <[email protected] >>>>>>> <mailto:[email protected]>> 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 >>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ gtk-osx-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-osx-devel-list
