Hi Andrew -- On 8/20/2023 3:58 PM, Andrew Kaster wrote: > Brian, > > I added a CMake option last week called ENABLE_NETWORK_DOWNLOADS that should > make one of your patches obsolete. Setting it to OFF should have the desired > effect. We recently added another required download for the Public Suffix > list from https://github.com/publicsuffix/list > <https://github.com/publicsuffix/list> as well. >
That's helpful. Setting things up manually beforehand is not all that difficult once you know what you need. > I'm surprised by your clang 15 -> clang 13 patch. Last time I tried to use > that version of clang to compile ladybird, the compiler ICE'd pretty badly. > I wasn't sure how to answer this when Linus said something, and I'm still not sure how to answer this. I have multiple reports from developers and users that Ladybird works on OpenBSD on amd64 and aarch64 with the in-base compiler. Whether that's because OpenBSD clang backported some fixes or some other reason, I don't know. > Ladybird is known to work on both amd64 and aarch64, fwiw. I've at least > tested it on aarch64 macOS and Asahi Linux (on the same Apple silicon > machine) > It also works on OpenBSD on an M2, reported by tobhe@: https://bsd.network/web/@tobhe/110748264101076472 > Your build script looks similar-ish to a few that I've been messing around > with for nixOS [1] and Flatpak [2]. I'm not sure what the best way around > manually setting up the Cache directory for the data files is though. > If there's a common strategy to ease maintenance for all portable targets, let me know I can move to that. > If you want /usr/local/ladybird/res then passing -DCMAKE_INSTALL_DATADIR > should do the right thing, assuming you also patch Ladybird/Utilities.cpp > to tell Ladybird where its "resource root" is (i.e. /usr/local/ladybird). > It should be /usr/local/share/ladybird/res to match the general package structure (I typo'd my original email), but the end result is the same. I did not try this but would be worth trying. > One snag with bumping up to a revision with ENABLE_NETWORK_DOWNLOADS is that > I moved the "current binary directory" detection logic out of Qt to > reduce the > dependence on Qt in the helper processes (WebContent, RequestServer, etc). > But all the googling I tried showed that OpenBSD doesn't have a good way to > figure that out aside from looking for argv[0] in $PATH. The logic is in > LibCore/System.cpp:1734 in current_executable_path. Of course for what it's > used for in Ladybird, one could simply hardcode "/usr/local/bin/foobar" and > it would probably work. > We would hardcode "/usr/local/bin/ladybird" for the OpenBSD package. I'll try to get a new package/port out over the next few days after updating the codebase and trying some of this out. ~Brian
