As mentioned, I’m on an M1 Mac where everything homebrew does is in
/opt/homebrew … there is no /usr/local “pollution” from homebrew on M1 Macs … I
agree that there may have been problems with the x86 version where homebrew
used /usr/local as its own fiefdom!
Now, as I said earlier in the thread, there is nothing at all in
/usr/local/lib. There is no environment member containing ‘homebrew’.
Looking at the situation with freetype, the simple fact is that something in
/opt should not and does not affect another packages or build systems. The
reasoning here is that package A is required to ignore package B when package B
is in /opt - this is a fundamental principle of unix filesystems for the past
few decades ! The upshot from this is that it's down to package A to not look
at or notice package B. If package A is that fussy, it has problems and won’t
do well. Whatever package A thinks, it has no option but to work around the
fact that /opt/B exists ...
The freetype build seems to be a problem - and it appears this is caused by
cmake putting the paths for fink, macports and homebrew into its search paths
for include files and libraries. If you look in:
<your gtk installation path>/inst/share/cmake-3.20/Modules/Platform/Darwin.cmake
… you will see …
— snip --
if(CMAKE_SYSTEM_NAME STREQUAL "Darwin" AND CMAKE_SYSTEM_PROCESSOR STREQUAL
"arm64")
list(PREPEND CMAKE_SYSTEM_PREFIX_PATH
/opt/homebrew # Brew on Apple Silicon
)
endif()
— snip —
This means that all CMake invocations by meson on M1 Macs will include
/opt/homebrew in the search path for include and libs.
This is wrong - very, very wrong.
The upshot of this is that to use your script as-is requires a special M1 Mac
with no homebrew, fink or macports on it - your advice/requirement to “build
using a different username” simply does not work reliably! That’s not a
sensible situation really is it?
Now, there is some traffic in the Cmake repo regarding a new flag that can be
sent to CMake to force it to omit some paths. Given that you want to keep all
the gtk stuff separate, this would mean telling CMake to not search
/opt/homebrew and /usr/local (at least - not check for fink/macports properly).
This would result in you being able to insulate your builds from whatever else
is installed on the Mac - you would simply include the system library paths in
CMake and omit everything else except within jhbuild’s world. That would be
sustainable …
See: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6880
<https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6880> for the new
CMAKE_SYSTEM_IGNORE_PREFIX_PATH parameter.
I think that when this version of CMake is released, it would make sense for
meson to pass the CMAKE_SYSTEM_IGNORE_PREFIX_PATH flag to CMake. Presumably
this could be done by jhbuild - but let’s see?
Meanwhile, thinking about gtk-osx-setup.sh, I think you could be missing an
opportunity - I think that on M1 Macs at least, you are perhaps being over
restrictive / prescriptive about homebrew. As things stand your script happily
ignores /opt/homebrew provided that homebrew is not in any environment
variables. Your script could even clean up the environment so that jhbuild is
not ‘polluted’ - this is very simple to do. In fact, the script is doing what
it is required to do to be a decent citizen, so I have no problem with it -
especially now that we have shaken down a couple of bugs. Once we have the
meson/cmake bug sorted out, your script and homebrew can peacefully coexist.
It could be that by embracing the fact that many or most developers need tools
from homebrew that you could attract more people to using gtk on MacOS? Perhaps
one way would be to have an example jhbuild-custom that removes homebrew paths
and perhaps sorts the cmake issue on M1 ?
If nothing happens, I expect you will get more comments from M1 based Mac
developers ...
Best
Paul
> On 17 Feb 2022, at 04:53, john <[email protected]> wrote:
>
> 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]
>> <mailto:[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
