Building Sigil on Haiku

[DiapDealer]

Originally Posted by User_Z

Yes, it would be very good to remove everything superfluous from it.

You misunderstand. Nothing in our cmake file is superfluous to the build process for the three platforms we support. We won't be removing anything from it. We would need to add conditionals/scenarios to better support Haiku.

But the fact is that you successfully compiled Sigil on Haiku. The only problem was either due to missing python modules, or you didn't install Sigil, and/or run it via the bash script launcher.

As for needing to shoehorn a different version of pcre into Sigil's third-party source folder, you probably didn't need to do that. You probably only needed to install an additional _dev (or _devel) package for pcre from your package manager to be able use the system version. The missing libpcre16 would have been provided by the dev package for pcre (or pcre2|3--whatever haiku's package manager calls it).

[User_Z]

Originally Posted by DiapDealer

As for needing to shoehorn a different version of pcre into Sigil's third-party source folder, you probably didn't need to do that. You probably only needed to install an additional _dev (or _devel) package for pcre from your package manager to be able use the system version. The missing libpcre16 would have been provided by the dev package for pcre (or pcre2|3--whatever haiku's package manager calls it).

This is already in the system. And if you substitute libpcre2-16, that fails.

[DiapDealer]

Originally Posted by User_Z

This is already in the system. And if you substitute libpcre2-16, that fails.

Yes. That's because there is no libpcre-16 package. The libpcre16 shared library is typically provided by the libpcre (or libpcre-dev[el]) package on most systems. If it's not on yours, then pcre was specifically built to leave out support for libpcre16. This is not something most systems do.

But regardless... as I previously mentioned, I believe you've already successfully built Sigil on your system. It's now just a matter of making sure the two required python modules are installed and that Sigil is being launched with the correct environment.

[Notjohn]

>Hi everyone.
>Need building manual Sigil on Haiku.
>Or your help.

It would be a more traditional haiku if revised as follows:

Greetings to forum.
Need Sigil build for Haiku
Or kind assistance.

[eschwartz]

Originally Posted by DiapDealer

Our cmake file would likely have to be adjusted quite a bit to fully accommodate Haiku. You can't really add additional include directories on the command line with cmake. But, I wouldn't really worry about any of the cmake output unless it's actually an error. Don't make the mistake of chasing all the include files found/not found unless the cmake configuration bombs.

Sure you can add additional include directories on the command line with cmake.

CFLAGS="-I/otherpath/include" cmake -DCMAKE_FLAGS_IN_USE=somevalue ..
make

It is true that cmake is an appalling, horrible build system that does its utmost to avoid letting either its users or its developers know that it is possible to either configure it outside of CMakeLists.txt or even simply be standards-compliant to very basic, very portable methods for configuring builds across a multitude of build platforms. For example, the NIH design of forking the pkg-config ecosystem to use homebrew FindFoo.cmake files which require all depending projects to also use cmake.

But that is neither here nor there, because you can get to it if you need it. Anyway, you can also use -DCMAKE_C_FLAGS="-I/otherpath/include".

/me gets off soapbox

Anyway, @User_Z Arch Linux uses very recent versions of all dependencies by forcing system libs, and it works quite well for us.

If you have any issues, you should take a look at the build docs for Linux: https://github.com/Sigil-Ebook/Sigil...ng_on_Linux.md

The build requirements will be mostly the same on most OSes, but the linux docs are specifically geared to environments that will be integrated into a wider system, unlike both Windows and macOS (the other officially supported platforms) which do things to carry around all their dependencies with them.

But yes, you are going to need something that provides libpcre16.so (I think Haiku uses the .so file extension for shared libraries?) which requires that your system pcre 8.43 is compiled with --enable-pcre16. In fact, it is extremely reasonable to compile pcre with both of the following two flags, see ./configure --help output:

  --enable-pcre16         enable 16 bit character support
  --enable-pcre32         enable 32 bit character support

This seems to be the HaikuPorts recipe for pcre: https://github.com/haikuports/haikup....43.recipe#L94

Note it includes neither of these flags. This alarms me. Please report a bug to the HaikuPorts project.

[eschwartz]

@KevinH, @DiapDealer,

Remember when I said qtwebengine was a problem for FSDG distributions in Linux-land? Apparently that's not the only place it is a problem.

In fact, I would venture to say that qtwebengine being built from chromium sources, it will be a problem getting qtwebengine on anything other than macOS, Windows, and glibc-using Linux distributions targeting 432-bit or 64-bit intel platforms.

I was recently chatting with some Void Linux people, who are apparently very dedicated and have dozens of patches to get webengine to build on the musl libc, alpine linux (another musl libc distribution) doesn't have it at all, and Debian only lists qtwebengine available for i386, amd64, arm64, armhf, and mipsel (no ppc support, for example).

So this also means OpenBSD does not have access to qtwebengine (there is a port, but it is marked as disabled and broken), NetBSD does not have access to qtwebengine (there is a port, but only in pkgsrc-wip, and I don't believe that really works either), and FreeBSD does actually have qtwebengine, surprisingly, but only by applying hundreds of patches and with a warning that it's so painful to update that it doesn't necessarily stay in sync with the rest of qt5.

It's an interesting pickle, to be sure.

[User_Z]

Notjohn

Согласен с Вами.
Наверное так было бы лучше, но я совсем не рифмоплётчик.

Прошу меня извинить, если моё первое обращение каким-либо образом оскорбило Ваши чувства.

[User_Z]

eschwartz

Thanks for the significant comment.
I also thought of rebuilding pcre, but for now a simple replacement of source code in "3rdparty" is working.

[DiapDealer]

Originally Posted by User_Z

eschwartz

Thanks for the significant comment.
I also thought of rebuilding pcre, but for now a simple replacement of source code in "3rdparty" is working.

There's no need to replace the 3rdParty source for pcre, though. The existing bundled source built just fine for me (and for Sigil) in the Haiku VM I set up using the same nightly build as you. All with Sigil 0.9.14, or course.

Forcing cmake to use the system python 3.6.8 and setting the install prefix to /system/non-packaged resulted in a working build of Sigil. Changing one line of Sigil Code fixed an issue with the preference/ini location. The system hunspell wouldn't work for the plugin framework since find_library('hunspell') returns None instead of the hunspell-1.7.so that Haiku chose, but that could be fixed with a symlink. The same python code on Arch succeeds in finding the hunspell-1.7 shared library, by the way.

All in all... a few hours work familiarizing myself with how to compile/install on the Haiku OS got me a working build of Sigil with plugin support (minus the glaring lack of tkinter availability for python 3.x from HaikuPorts.

[User_Z]

DiapDealer

This is just great!
Congratulations. Another system conquered in the development of multisystems.

Please share step by step instructions and files.

[DiapDealer]

I patched src/Misc/Utility.cpp (at Sigil v0.9.14 ) with the attached patch file. Apparently Qt's QStandardPaths::(App)DataLocation returns "None" on Haiku. Change to QStandardPaths::ConfigLocation in DefinePrefsDir() in src/Misc/Utility.cpp (I'll look into defaulting to this in master whenever (App)DataLocation is None).

EDIT: No patchfile just yet. Too hard to get a file out of the VM with no working guest additions. The simple change is documented in the attached instructions.

I used the System Python 3.6.8 because Python 3.7.3 seemed incomplete. All the latest ****-python3 modules packages in HaikuPorts were for 3.6 anyway, so it seemed easier. I always like to use system packages wherever possible.

After that, it was the configure command (included in the instructions), make/make install like normal.

[DiapDealer]

Originally Posted by eschwartz

@KevinH, @DiapDealer,

Remember when I said qtwebengine was a problem for FSDG distributions in Linux-land? Apparently that's not the only place it is a problem.

In fact, I would venture to say that qtwebengine being built from chromium sources, it will be a problem getting qtwebengine on anything other than macOS, Windows, and glibc-using Linux distributions targeting 432-bit or 64-bit intel platforms.

I'm just not able to get too worked up over this. Sigil 0.9.14 works quite well, and anybody who just HAS to have the latest version of Sigil on an OS it can't be built on, can always use it in a VM that DOES support it. I'm quite happy with the current range of distros/platforms/architectures the latest version of Sigil will build on. And I expect that range will only get broader as time goes on.

Situations like this are exactly why forks happen. If it's important enough to someone, they'll make it happen (and share).

[eschwartz]

Originally Posted by DiapDealer

I'm just not able to get too worked up over this. Sigil 0.9.14 works quite well, and anybody who just HAS to have the latest version of Sigil on an OS it can't be built on, can always use it in a VM that DOES support it. I'm quite happy with the current range of distros/platforms/architectures the latest version of Sigil will build on. And I expect that range will only get broader as time goes on.

Situations like this are exactly why forks happen. If it's important enough to someone, they'll make it happen (and share).

Yeah, I agree there's far too much that needs this (and webengine is far too significant a usability and safety improvement over webkit). There's not really anything else to do other than I guess complain to Qt that they chose an ecosystem which is kind of actively hostile to heterogeneous environments.

[User_Z]

Hurrah! Hurrah! Hurrah!

This is just some kind of miracle. Glory to DiapDealer!!!

Today is truly a momentous day. Remember all of it.

Hardware: Intel Pentium 4 3.2 GHz, Socket 478
Operating system: Haiku x86_64
Software: Sigil 0.9.14

All system libraries are used (on the advice of eschwartz rebuilt pcre).

-- Found ZLIB: /boot/system/develop/lib/libz.so (found version "1.2.11") 
-- Found PkgConfig: /bin/pkg-config (found version "0.29.2") 
-- Found MiniZip: /boot/system/develop/lib/libminizip.so
-- Checking for module 'hunspell'
--   Found hunspell, version 1.7.0
-- Checking for module 'libpcre16'
--   Found libpcre16, version 8.43
-- Found PythonInterp: /bin/python3.6 (found suitable version "3.6.8", minimum required is "3.6.8") 
-- Found PythonLibs: /boot/system/develop/lib/libpython3.6m.so (found suitable version "3.6.8", minimum required is "3.6.8") 
-- Using System ZLIB
-- Using System MiniZip
-- Using System Hunspell
-- Using System PCRE

Many thanks to everyone who took part in this serious matter.

And finally, the hero of the occasion:

[DiapDealer]

I love a happy ending!