Building the Linux standalone Sigil installer

[eschwartz]

There is no real reason to use makeinstaller if you are building yourself.

It's purpose is to create a fully redistributable "frozen" version which can be installed by anyone -- even if they don't have python3, Qt5, etc. -- and installs into /opt


And if you look at src/CMakeLists.txt, the linux_python_gather.py is created if you define PKG_SYSTEM_PYTHON, which of course is necessary if you will be making a standalone installer.
makeinstaller just runs that file, I think from looking at it it should be complete.
But I certainly haven't tried it...

...

Why are you using checkinstall instead of a proper package manager? I don't know much of anything at all about using debian's buildsystem, but I *think* they have some way of building the git version of a package.
All I know is it is much easier with ArchLinux -- hey, I maintain the sigil-git package.

[DiapDealer]

Originally Posted by st_albert

It built fine on linux (Kubuntu 14.04, Qt5.4.1) and I noticed a build target "makeinstaller." But alas, it errored out because it couldn't find "linux_python_gather.py"

Correct me if I'm wrong, but I'm assuming that makeinstaller is not fully implemented yet. When it is, though, that'll be nice to have.

Yes makeinstaller is very preliminary and unsupported at this time (as indicated in the CMakeLists.txt file). There are several dependencies that must be met (including a patched Makeself v2.2.0, and chrpath on your PATH) before attempting to build it.

There's also some cmake variables to help locate the various TK/TCL pieces. It's what I'm going to use to create stand-alone Linux installers when I get some kinks worked out. I'll get it all documented when it's more stable, but if you want to play in the meantime, add -DPKG_SYSTEM_PYTHON=1 to your initial cmake command if you want to get past the error you got.

Just don't try to install normally (sudo make install) after configuring with PKG_SYSTEM_PYTHON. It won't work.

But as eschwartz said: it won't be very useful to those just installing for themselves. It doesn't make sense to package up python and Qt5 and then reinstall them in a different location on your machine. It's going to be used to distribute standalone installers for those who don't WANT to install all the dependencies and build it for themselves.

Hopefully the various repos will be able to include the latest versions of Sigil (and make the installer moot), but if they don't/can't/don't want to--or even if we just get ahead of a few of them, it'll be nice to have the option.

[st_albert]

Originally Posted by eschwartz

There is no real reason to use makeinstaller if you are building yourself.

It's purpose is to create a fully redistributable "frozen" version which can be installed by anyone -- even if they don't have python3, Qt5, etc. -- and installs into /opt

Yes, I understand that. But it's useful to me because in our shop I have three linux boxes, all Kubuntu Trusty, on which I want to deploy Sigil. Packaging it up --even a quick and dirty package via checkinstall-- would mean I don't have to maintain the build environment on each of the three machines.

From DiapDealer's post, it looks like I don't have some of the dependencies I'd need anyway, so for now I will just do the separate builds.

Thanks for the information!

Albert

[eschwartz]

Then try passing -DPKG_SYSTEM_PYTHON=1 to cmake, and setting all the environment variables to the right locations in src/Resource_Files/python_pkg/python_paths.py

I imagine at some point the makeinstaller logic will be further fleshed out, i.e. it should be attempting to find the location of things using pkg-config cmake find_packages() if not explicitly specified.
But it might work as of now, too.

...

checkinstall does not stop you from needing to install dependencies last I checked... so I really don't see what benefit checkinstall has over an actual *.deb built from the official Debian packaging sources.

[DiapDealer]

Originally Posted by eschwartz

Then try passing -DPKG_SYSTEM_PYTHON to cmake, and setting all the environment variables to the right locations in src/Resource_Files/python_pkg/python_paths.py

Has to be -DPKG_SYSTEM_PYTHON=1

There's no need to set any of the variables in python_paths.py as env vars. Those variables get filled when cmake configures it. Many are provided already by the existing cmake build process. The few that might be needed to build the standalone installer can be provided as -D options in the initial cmake command (if cmake can't locate them on its own).

It builds for me with little effort.
The plan IS to flesh it out and make it build for everybody, but that may be a while.

[eschwartz]

Of course, =1 ('twas a typo )
I tried running makeinstaller and it errored on copying tk/tcl

pkg-config/find_packages

So, looking at the configured python_paths.py, it would seem that it is helpful if the makeinstaller custom command asked to find_package(TCL)
But I still can't find anything to provide ${TCLTK_SUPPORT}


And obviously, take as long as you need to. I was just making a couple, hopefully helpful, observations to help @st_albert get a successful build without waiting.

[DiapDealer]

Originally Posted by eschwartz

Of course, =1
I tried running makeinstaller and it errored on copying tk/tcl

pkg-config/find_packages

So, looking at the configured python_paths.py, it would seem that it is helpful if the makeinstaller custom command asked to find_package(TCL)

I've, of course, secretly patched my own top-level CMakeLists.txt file to do just that. But it's still not entirely necessary. You can always use -DTK_LIBRARY=<path> and -DTCL_LIBRARY=<path> to set the paths to tcl8x.so and tk8x.so respectively.

But I still can't find anything to provide ${TCLTK_SUPPORT}

That's the prefix to the tcl8x and tk8x data directories (which contain all the *.tcl files). On my build system, that's -DTCLTK_SUPPORT=/usr/local/lib. I know it's /usr/share/tcltk on some package-based systems.

The only other things needed (aside from all the extra Python3 modules listed in the docs) should be having chrpath installed, and having makeself v2.2.0 (it only needs patched if you're going to create a system-wide installer) somewhere on your path (I just create links to makeself.sh and makeself-header.sh in /usr/local/bin).

At least I think that's currently all.

And obviously, take as long as you need to. I was just making a couple, hopefully helpful, observations to help @st_albert get a successful build without waiting.

No problem. Always happy to let others play. I am going to move this discussion to its own thread, though.

[eschwartz]

EDIT: cross-posting.

-DTCLTK_SUPPORT=/usr/lib
Passes.

def copy_strip_icu5(ver='53'):
Epic failure on my system which has icu 56.1-2 installed.
s/53/56/g

libqtaudio_alsa.so appears to have mysteriously disappeared in my distro's qt5-multimedia package during the C++11 rebuilds , xxx that out for testing...

makeself.sh cannot possibly exist , it only exists as a file to be *executed* at src/Resource_Files/python_pkg/linux_python_gather.py:455


And there endeth the experimentation.
Overall, not bad.

[DiapDealer]

Originally Posted by eschwartz

def copy_strip_icu5(ver='53'):
Epic failure on my system which has icu 56.1-2 installed.
s/53/56/g

Well at least you can see I planned to make that parameter configurable.

[eschwartz]

Originally Posted by DiapDealer

That's the prefix to the tcl8x and tk8x data directories (which contain all the *.tcl files). On my build system, that's -DTCLTK_SUPPORT=/usr/local/lib. I know it's /usr/share/tcltk on some package-based systems.

I did figure that out, but there doesn't seem to be any cmake find_package(), which is less convenient but could still be gotten automatically with pkg-config I suppose.

The only other things needed (aside from all the extra Python3 modules listed in the docs) should be having chrpath installed, and having makeself v2.2.0 (it only needs patched if you're going to create a system-wide installer) somewhere on your path (I just create links to makeself.sh and makeself-header.sh in /usr/local/bin).

That would explain it. I didn't expect to see a *.sh file called from outside the source tree.

At least I think that's currently all.

No problem. Always happy to let others play. I am going to move this discussion to its own thread, though.

Sure thing.

[eschwartz]

Originally Posted by DiapDealer

Well at least you can see I planned to make that parameter configurable.

Yeah. Again, early days, so I don't expect it to be production-ready (works @world).