Problems building Sigil on Win7/64

[Man Eating Duck]

Hi! I'd like to build Sigil from source on Win7/64, both to get a sneak preview of features, and to maybe aid minorily in development (although the following question might suggest that I'm a noob coder, I have been known to contribute usefully to other C++ projects in the past, using Linux).

I don't want the devs to waste their time with me, but I ask others who have successfully compiled it whether they could share their notes about the steps necessary to do so. I don't use VS, and thus tried the alternate method with the windows SDK. I'm not well versed with building under Windows, but have successfully compiled lots of things from source under Linux. It just seems a lot easier

So what I would like to see is a step-by-step description of how to get from a fresh install of win7 to being able to compile Sigil (without VS, as I don't have a licence and wouldn't want to be dependent on it in the future). From there I could likely figure where I'm stuck, and what I need to do. If anyone has made notes, I'd appreciate seeing them.

I installed all the dependencies mentioned in the readme, which was an adventure in itself (turns out that you have to uninstall the C++ 2010 runtimes, otherwise the Windows SDK install will error out with a nonsensical error message referring to a non-existant local html file. Makes perfect sense).

I currently gave up with a (probably simple) "Could NOT find Qt4 (missing: <a lot of stuff>) error from cmake, including QT_QMAKE_EXECUTABLE. I find qmake.exe 14 times in the QT tree, and none of the seem to work when referencing them (Windows additionally gave me a "path environment variable too long" error on some of them. As we all know, computers easily get bored when they have to read long text strings. They are not good at handling large amounts of data accurately, especially when the amount of data is immense, to the tune of about 2300 characters).

Ok, enough with the snide remarks. Could anyone post their notes about this?

[PeterT]

I wonder if the VS Express would suffice for calibre building?

[Serpentine]

You could likely get away with using CodeBlocks, QtCreator, CodeLite? or Eclipse - all will require a bit of playing around.

At the moment it sounds like you're trying to use the cli interface for CMake, try using the cmake gui - it makes life a lot easier.

[Man Eating Duck]

Originally Posted by Serpentine

At the moment it sounds like you're trying to use the cli interface for CMake, try using the cmake gui - it makes life a lot easier.

Of course I did try cli first, why shouldn't that work?
I also tried cmake-gui, it complained that cmake.exe (not qmake.exe, no spelling mistake) was not found, I'm pretty sure I have it as I installed them together (and cmake runs from cmd without a path appended). Shit happens.

I'm currently installing VS Express 2012 as per PeterT's suggestion. I'm probably missing something stupid, but I'll probably also come back to you for further advice

[Serpentine]

Originally Posted by Man Eating Duck

Of course I did try cli first, why shouldn't that work?

It works fine when everything is correctly detected, but if you need to do manual configuration it's pretty tricky to get a quick overview of things. The gui also somewhat guides you through problems.

It sounds like you used the zip, rather than the installer to 'install' cmake, if so it can get quite annoying in regards to not finding the cmake detection rules and stuff, since it will work, but tries to look for stuff in PATH, rather than the local directory... it seems anyway. Just remember that if you've manually moved libs and sdk's around, cmake will not be able to guess that, you may have to tell it where your new location is (as it does find some stuff from registry keys).

Not sure about VS Express, but since there's no MFC or anything like that, it may work.

[kiwidude]

@Man Eating Duck - did you remember to put the Qt bin folder into your path, *before* running the cmake command line?

[Man Eating Duck]

You shouldn't waste your time on me

I made a stupid mistake, I added paths to my user account, while the SDK cmd runs as administrator. I added "D:\QtSDK\mingw\bin" to the system path, and I still get an error while running "cmake ." [Should I run that with no target? Does that question even make sense? ] after adding the path to the System path, however, it's probably another mistake of mine. The file C:\Users\andlia\AppData\Local\Temp\nmE9D.tmp did not exist when I tried to retrieve it. I'm on thin ice in Windows, I'm sorry...

D:\prog\sigil>cmake .
-- Building for: NMake Makefiles
-- The C compiler identification is MSVC 16.0.30319.1
-- The CXX compiler identification is MSVC 16.0.30319.1
-- Check for CL compiler version
-- Check for CL compiler version - 1600
-- Check if this is a free VC compiler
-- Check if this is a free VC compiler - no
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 10.0/VC/bin/amd64/cl.exe -- broken
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
  The C compiler "C:/Program Files (x86)/Microsoft Visual Studio
  10.0/VC/bin/amd64/cl.exe" is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: D:/prog/sigil/CMakeFiles/CMakeTmp



  Run Build Command:nmake /NOLOGO "cmTryCompileExec2829198104\fast"

        "C:\Program Files (x86)\Microsoft Visual Studio
  10.0\VC\Bin\amd64\nmake.exe" -f
  CMakeFiles\cmTryCompileExec2829198104.dir\build.make /nologo -L
  CMakeFiles\cmTryCompileExec2829198104.dir\build

        "C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_progress_report
  D:\prog\sigil\CMakeFiles\CMakeTmp\CMakeFiles 1

  Building C object
  CMakeFiles/cmTryCompileExec2829198104.dir/testCCompiler.c.obj

        C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe
  @C:\Users\andlia\AppData\Local\Temp\nmD63.tmp

  testCCompiler.c

  Linking C executable cmTryCompileExec2829198104.exe

        "C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E vs_link_exe
  C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe /nologo
  @CMakeFiles\cmTryCompileExec2829198104.dir\objects1.rsp
  @C:\Users\andlia\AppData\Local\Temp\nmE9D.tmp

  LINK : fatal error LNK1123: failure during conversion to COFF: file invalid
  or corrupt

  LINK Pass 1 failed.  with 2

  NMAKE : fatal error U1077: '"C:\Program Files (x86)\CMake
  2.8\bin\cmake.exe"' : return code '0xffffffff'

  Stop.

  NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
  10.0\VC\Bin\amd64\nmake.exe"' : return code '0x2'

  Stop.





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:12 (project)


-- Configuring incomplete, errors occurred!

D:\prog\sigil>

[Man Eating Duck]

Originally Posted by Serpentine

It works fine when everything is correctly detected, but if you need to do manual configuration it's pretty tricky to get a quick overview of things. The gui also somewhat guides you through problems.

It sounds like you used the zip, rather than the installer to 'install' cmake, if so it can get quite annoying in regards to not finding the cmake detection rules and stuff, since it will work, but tries to look for stuff in PATH, rather than the local directory... it seems anyway. Just remember that if you've manually moved libs and sdk's around, cmake will not be able to guess that, you may have to tell it where your new location is (as it does find some stuff from registry keys).

Not sure about VS Express, but since there's no MFC or anything like that, it may work.

Thanks for your help
I installed everything from downloaded install files, no manual trickery at all except for custom location (but I don't believe that being installed on d: instead of c: will matter).

I get a lot more, and uglier, error messages from the cmake-gui than from cli, I strongly suspect that the problem is that I miss something obvious. Hence the request for notes from someone who did manage to set it all up.

The path problem was my mistake, I set the path for my user, while the SDK cmd runs as admin.

On a side note I'm comfortable with the cli, even on Windows, I have a full range of relatively POSIX-compliant cli utilities installed on my Win7 computer at work (and my Win7 partition at home). Highly recommended if you're used to Linux/Unix/BSD

[kiwidude]

@Man Eating Duck - I use VS 2010 to develop, so I can't give you a completely 100% list for what you need to do without that installed.

However I did a few days ago setup a cmake/nmake directory for building outside of VS to test something, so I can tell you what I did for that... (Windows builds only).

If John or anyone else spots any obvious errors, tell me and I will correct the post.

Preparation work:

Spoiler:

• All directories in my example are based in D:\SigilDev but you can adjust to your preference.
• Install the Windows SDK (or in my case VS 2010)
• Install git (assuming you are working from a git repository of Sigil) to retrieve source code from trunk using:
• git clone https://code.google.com/p/sigil/ D:\SigilDev\sigil-head
• Install Inno Setup 5 (if you intend to build the nmake based MSI installer) to D:\SigilDev\Tools\Inno Setup 5
• Install Qt 4.8.3 using the installer from the Qt website (no need to build yourself as a Windows user for 32-bit anyways). Get the right install for the type of build (e.g. VS2010 in my case). Install so the binaries for this example are put in D:\SigilDev\Qt\4.8.3\bin
• Install cmake 2.8.8 and add the D:\SigilDev\Tools\cmake-2.8.8-win32-x86\bin directory to system path.

To create an nmake based debug build:

Spoiler:

• Create an empty directory to do building from, e.g. D:\SigilDev\sigil-nmake-debug
• Open a command prompt - in your case a Windows SDK command prompt (in my case a VS command prompt).
• Switch directory to D:\SigilDev\sigil-nmake-debug
• Ensure Qt is in your path:
• SET PATH=D:\SigilDev\Qt\4.8.3\bin;%PATH%
• Then run the cmake/name combination:
• cmake -G "NMake Makefiles" D:\SigilDev\sigil-head
• nmake

After running that (assuming no errors) you will have a D:\SigilDev\sigil-nmake-debug\bin folder containing Sigil.exe ( + debug symbols). Note that you cannot run it from there without all the supporting files.

Copy all the subfolders from your official Sigil beta install directory (codecs, examples, hunspell_dictionaries, etc) into your bin folder at D:\SigilDev\sigil-nmake-debug\bin

You will also want the Qt debug dlls. You can find those in the D:\SigilDev\Qt\4.8.3\bin folder. You want to copy a subset of them into your bin folder above too. Make sure they have the d4.dll suffixes - specifically: phonond4.dll, QtCored4.dll, QtGuid4.dll, QtNetworkd4.dll, QtSvgd4.dll, QtWebKitd4.dll, QtXmld4.dll, QtXmlPatternsd4.dll (the ones in your Sigil MSI installed folder are of course the release not the debug dlls).

Now you should be able to run the Sigil.exe If you edit the source code back in the D:\SigilDev\sigil-head folder, then just re-run the nmake step.

To create an nmake based release build / 32-bit MSI installer:

Spoiler:

• Create an empty directory to do building from, e.g. D:\SigilDev\sigil-nmake-release
• Open a command prompt - in your case a Windows SDK command prompt (in my case a VS command prompt).
• Switch directory to D:\SigilDev\sigil-nmake-release
• Ensure Qt is in your path:
• SET PATH=D:\SigilDev\Qt\4.8.3\bin;D:\SigilDev\Tools\In no Setup 5;%PATH%
• Then run the cmake/name combination:
• cmake -G "NMake Makefiles" -D CMAKE_BUILD_TYPE=Release D:\SigilDev\sigil-head
• nmake makeinstaller

The MSI installer will be located in: D:\SigilDev\sigil-nmake-release\installer

If you want to just run the Sigil.exe from the bin folder, you need the same trick I mentioned under debug of the supporting folders and Qt dlls (release versions). Probably easier just to run the MSI installer, then copy *all* the supporting files/folders from that install folder back into your D:\SigilDev\sigil-nmake-release\bin folder

To create a VS 2010 based build:

Spoiler:

• Create an empty directory to do my building from, e.g. D:\SigilDev\sigil-vs2010
• Open a command prompt - in your case a Windows SDK command prompt (in my case a VS command prompt).
• Switch directory to D:\SigilDev\sigil-vs2010
• Ensure Qt is in your path:
• SET PATH=D:\SigilDev\Qt\4.8.3\bin;%PATH%
• Then run cmake:
• cmake -G "Visual Studio 10" D:\SigilDev\sigil-head
• Open the Sigil.sln file in VS 2010 (which has Debug, Release, RelWithDebInfo and MinSizeRel solution configurations).
• Set Sigil to be the startup project.
• Build Sigil

After running that (assuming no errors) you will have a D:\SigilDev\sigil-vs2010\bin\Debug folder containing Sigil.exe (+ debug symbols). Note that you cannot run it from there without all the supporting files.

Copy all the subfolders from your official Sigil beta install directory (codecs, examples, hunspell_dictionaries, etc) into your bin folder at D:\SigilDev\sigil-nmake-debug\bin

You will also want the Qt debug dlls. You can find those in the D:\SigilDev\Qt\4.8.3\bin folder. You want to copy a subset of them into your bin folder above too. Make sure they have the d4.dll suffixes - specifically: phonond4.dll, QtCored4.dll, QtGuid4.dll, QtNetworkd4.dll, QtSvgd4.dll, QtWebKitd4.dll, QtXmld4.dll, QtXmlPatternsd4.dll (the ones in your Sigil MSI installed folder are of course the release not the debug dlls).

At this point you are set - you should be able to edit and run the Debug configuration in VS.Net 2010. If you build any of the Release solution configurations, remember to copy the appropriate set of Qt dlls and supporting folders as described in the above steps.

There are more complications if you want to build the 64-bit build/installer - not something I have done as yet. The instructions John gave me a long time ago are included below for completeness:

Spoiler:

Using the Visual Studio command shell (it sets up the environment
properly) I use Bin\SetEnv.exe /release. Then build Qt x64 using the Qt instructions on the build instructions Wiki. Then open a new shell and Bin\SetEnv.exe /release /x86 (I think it's x86) to put it into 32 bit build mode. Build Qt in a different directory for a 32 bit version.

Once Qt is built, open another command shell (I use a fresh one each time so the env is rest). Set it for release. Then set the path to have both Qt (the proper one for the build type) and Inno in the path.
cd to Sigil's directory,

$ cmake -DCMAKE_BUILD_TYPE=Release -DWIN_INSTALLER_USE_64BIT_CRT=1 $ make $ make makeinstaller

Then do it again with a new shell but with x86 set as the environment and don't use the 64BIT_CRT option when running cmake.

Right now Sigil only builds with Microsoft's compiler so don't try to use cygwin or mingw. The ability to use something other than Microsoft's compiler on Windows is a long term goal. So is using cpack to help with the installer building process.

Also, the WIN_INSTALLER_USE_64BIT_CRT is very important on x64 builds.
Sigil distributes the CRT instead of having you or automatically downloading and installing it. That directive tells the installer which one to put in the installer.

I'll also point out that I build using Windows x64. I don't know if it's possible or how to do so with a 32 bit install.

[DiapDealer]

Your instructions for cmake/nmake seem spot-on to me. That's how I did it on Windows. I've never done much building on the Windows platform before, but it seemed fairly painless.

[kiwidude]

@DiapDealer - thanks very much for confirming that. What I know about cmake/nmake wouldn't fill a paragraph.

I will add this as a warning to anyone out there doing Visual Studio 2010 builds of Sigil and then using them. As brilliant as it is for debugging Sigil, there are a number of issues I have found with the executables it produces. These result in very undesired behaviour in Sigil and can have you panicking about bugs in the code that don't exist when you do an nmake build.

Here are just two examples I have seen:

• Saving an EPUB using results in a corrupted mimetype file. It isn't the 20 byte uncompressed file it should be.
• In BookView, clicking within a paragraph so there is no selection and then pasting (ctrl+v or via right-click) will delete from the mouse position until the end of the paragraph block.

Exactly why these issues happen I have no clue. The fault does not lie in the Sigil code itself, which works fine using nmake.

My guess is that the fault lies in the cmake configuration somewhere - some flags are not being set for the Visual Studio configuration that are in the nmake one. So if there are any cmake gurus out there who also have Visual Studio and want to nut this one out I would be extremely grateful...

[Man Eating Duck]

Originally Posted by kiwidude

@Man Eating Duck - <Lots of instructions>

I am finally able to build head, these instructions are invaluable

Thanks a lot, kiwidude!

A few points if anyone else has problems (these are probably newbie mistakes), no need to read the rest if you're OK.

It's been a long-ish process, mainly reinstalling the SDK and NET 4 components. Before installing the SDK, uninstall any C++ 2010 redistributables. If not you'll get bizarre problems.

The vast majority of my time went to reinstalling the SDK and/or NET 4. The installers seems to muck up each others installs at times. For me this resulted in "cl is not able to compile a simple program", LNKXXXX errors or a host of other problems (for which the suggested solution from Googling invariably was "reinstall something"). Uninstalling via the normal interface frequently just froze. I used uninstall tools for VS 2010 and the SDK instead. I have really no idea why it worked in the end, so I can't provide good instructions.

After getting "a simple program" to compile I got a lot of errors about x64/x86 mixups when linking. Again, I tried a lot of tips from Google which got me a small bit further, not too sure what clinched it. But I do know that having the VC/bin/amd64/cl.exe in your path might make the SDK use that instead of the x86 one, giving problems to the linker. Remove the path entry if it's there.
I also had to add -D "CMAKE_EXE_LINKER_FLAGS=/STACK:10000000 /machine:x86" to the cmake command line, again that's probably because I mucked something up. After correcting arch stuff, nmake clean seems necessary.

This post didn't turn out to be very useful after all... but it reflects my confusion after this process