> On Dec 2, 2025, at 09:29, Robert Helling <[email protected]> wrote: > >> On 2. Dec 2025, at 16:13, Dirk Hohndel <[email protected]> wrote: >> >> Well, we're making progress. >> How did you install Qt 6 ? >> I worry that you may have done so using home-brew which would explain some >> of your problems. >> Please install the actual Qt Company macOS version, ideally in a separate >> path like /opt/Qt/ , and then call the build process again (the full >> script), starting with an empty directory. I want to make sure we really >> sort out the dependencies and make this truly reproducible. > > This so far did not work: I had downloaded a fresh Qt using Qt’s own > installer and placed it in ~/Qt but that was not picked up. On my work Mac, > this lead to a build failure but once I had installed qt@6 using homebrew the > build succeeded (similar for libftdi). I did not create any symlinks (wasn’t > that required at some point in the past?). How can I force it to use the Qt > in my home directory?
This is the story of my life trying to deal with Homebrew and our dependencies on macOS. Every single time I try to add something I hit that same loop: - something doesn't work - I do something - something else doesn't work - I keep doing things The solution is to stop at the first step that doesn't work and ask yourself "WHY IS THAT"? The problem is almost certainly a combination of (a) your $PATH and (b) settings from a previous, failed build. So, when a build fails and you make ANY changes, ALWAYS do "rm -rf subsurface/build" Yes, you shouldn't need that. And yes, you will absolutely regret if you don't do it. Don't ask me how many hundred hours I have wasted on things that later turned out to be caused by not removing the complete build directory. So, I guess my script should have started earlier in the process. (1) install the official Qt binaries for macOS in your ~/Qt (2) set your PATH to ~/Qt/6.10.1/macos/bin:$PATH [[ or which ever version you installed ]] (3) rm -rf subsurface/build now run the script I gave you. >> For example, at no point in the process should there have been a y/n >> question for you to answer... >> >> The binary this produces (tested with the official Qt 6.8.3 binaries and the >> official Qt 6.10.1 binaries) has working maps, working bluetooth, working >> MTP, working ftdi (all tested here). >> >> As for the user manual, I am half way there with a replacement solution for >> that. It's not perfect, but will likely meet the "good enough" standard. > > Which direction are you pursuing here? I mentioned this in this thread. qlitehttp https://code.qt.io/cgit/playground/qlitehtml.git/ it's an obscure little project that the qttools team themselves are using for the exact same purpose. it uses https://github.com/litehtml/litehtml to position the elements. And from reading the source it even has some rudimentary support for printing things... Right now I am fighting the usual fight of actually getting this to build and package as intended (see above - I fell into the same trap of not removing the build at one point). The first successful attempt shows the manual without the index (that requires Javascript - easy to fix) and without the ability to search. Work in progress > What is the perspective regarding Webkit and Qt6? Dead. Abandoned. Impossible. Hence the direction mentioned above. /D
_______________________________________________ subsurface mailing list -- [email protected] To unsubscribe send an email to [email protected]
