Quote:
Originally Posted by darkbreath
Do those directories look right?
|
Yes. That looks right.
Quote:
Originally Posted by darkbreath
Oh ok, this right here was the problem. I double-clicked Sigil in the build directory just like you said  . When it didn't run, I did a ./sigil in the same directory to figure out what the problem was. The error messages mentioned those libraries, which is when I made links to the library files in my build directory and placed the links in /usr/lib, and then Sigil ran successfully. I was actually pretty happy that it ran. I'm no programmer so I figured when Sigil installed, it was to the build directory. Running the binary from /usr/local/lib/sigil directly caused the test plugin to pass all tests! |
Yes. Running Sigil from the build directory is not recommended for anyone other than developers. The environment Sigil needs to run properly is not complete in the build directory. It's only a staging area for the libraries and binaries that were compiled.
After installing, the way to run Sigil is to type "sigil" at a teminal, or to use the menu entries added to your Desktop Environment's "Office" and/or "Accessories" submenus. You can usually create a shortcut on your desktop by right-clicking on one of those Sigil menu entries. Launching sigil by double clicking the /usr/local/lib/sigil/sigil file is not recommended (even if it seems to work). The launch script (/usr/local/bin/sigil) sets ceratin environment variables that are necessary to ensure the proper environment exists for Sigil and its plugin framework.
And for the record, there's no "programming" skills required for building and installing Sigil. It's all administrative tasks and knowledge of (and familiarity with) the command line. That may sound a bit picky, but there really is a difference. None of this is "programming."
Quote:
Originally Posted by darkbreath
So if I'm not mistaken, the compiler first created binaries in the build directory, then copied the binaries to /usr/local/bin/sigil, right? Because that would explain why there are 2 copies of the binaries. It's actually great that it works that way.
|
Yes. See my "staging area" reference above.
Quote:
Originally Posted by darkbreath
I tend to move the build directory around a lot (so I can back it up as part of another folder).
|
Don't do this. Unless you're a developer who wants to see the result of a quick change to the source code without compiling everything all over again, there is no reason to hang on to the contents of the build directory (with the lone exception of a single file I'll get to later). It can only confuse you--as witnessed here in this case. Delete it. When you want to upgrade, download the new source, create a new build directory and start from scratch. Compiling newer source with the existing build directory of a previous version is a recipe for disaster for those not comfortable with configuring/compiling.
Quote:
Originally Posted by darkbreath
If checkinstall had decided to link the temporary location of the build folder to the Sigil package, then I would be in real trouble.
|
In short: it won't. Checkinstall will be bound by the same install rules as "make install." It just gives you a way to easily uninstall/reinstall the same version (but typically only on the same machine).
Quote:
Originally Posted by darkbreath
Ok, so I have two last questions regarding this topic:
1. Is there a general way to uninstall programs that have been installed with make install? I used checkinstall partially because I couldn't find such a method. In fact, I couldn't even find a way to track the changes done by make install (so that I can reverse the changes manually later).
|
No there's not. Not with CMake generated makefiles, at least. But Sigil is not all that hard to uninstall manually. "Make install" creates an "install_manifest.txt" file that lists every file installed and where it was installed to (minus the Qt5 dependency files obviously). It's the one file from the build directory that a non-developer should consider hanging on to. It may look overwhelming, but it's really all two directories and three individual files that need to be removed to "uninstall" Sigil (if you installed with a standard "make, make install")
Directories:
/usr/local/lib/sigil
/usr/local/share/sigil
Files:
/usr/local/bin/sigil
/usr/local/share/applications/sigil.desktop
/usr/local/share/pixmaps/sigil.png
If you change Sigil's INSTALL_PREFIX, just replace /usr/local with the prefix you've chosen.
There's the preferences directory where settings and plugins are stored (created only after Sigil first runs on any machine), but that's not typically deleted. But you can--if you like--for a completely clean slate, by deleting the $HOME./local/share/sigil-ebook directory. The .local directory and its contents is typically hidden. I don't recommend removing the $HOME./local/share/sigil-ebook directory if you don't want to lose all of your preferences, plugins ... and plugin preferences.
Quote:
Originally Posted by darkbreath
2. If I compile a newer version of a program from source and try to make install with the old version still untouched, what happens? Is this generally a good idea? I used checkinstall partially so I could get rid of all traces of the old version because I didn't know what would happen if I didn't.
Thanks
|
As eschwartz mentioned, it's typically no problem installing a new version over the old. It would only potentially be an issue if there was some sort of huge overhaul of the Sigil installation structure/location or the run environment. Not very likely (and certainly not likely without a huge warning from me to Linux users).