News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Windows nightly build error.

Started by DrSuperGood, September 05, 2014, 04:12:49 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DrSuperGood

Some people might have noticed that the Windows nightly build has not been working for nearly 3 months now. Over the course of this time several bugs have been fixed, including some which were in RC120. One can still build a Windows version manually using the Windows SDK and a C++ compiler however this requires some computer knowhow which is probably beyond the majority of people who just want to play the game (not developers).

The error appeared to be introduced when changes were made to try and introduce a better font/typeface system. These only apply to the Windows build (compiler switch) with those sections doing nothing for OSX and Linux. The specific cause is that a new include dependency "Shlobj.h" was added (usually included with the Windows SDK) which is not available on the nightly build server. It appears to provide shell functionality which includes fetching type faces.

This raises a few questions as to why this particular header is not on the build server. Is it because the build server uses a different Windows SDK (which does not include that header)? Or is the SDK used just the minimum to allow for compilation and requires updating with new dependencies?

If it is only available in some Windows SDKs (I know it is in the official Microsoft one) then maybe a compiler switch could be used. Alternatively it might be worth reverting the commit until a solution to it is found to allow automatic Windows nightly builds as the more people who can test them, the more likely bugs are to be found.

Ters

The build server doesn't use Windows SDK at all. It's a Linux box doing cross-compiling (which Windows SDK doesn't support) with various flavours of GCC. For Windows, this is mingw. There are however several of us that use mingw, so I don't think that's the cause. There was initially a problem with the new font system and mingw, but that was fixed.

Furthermore, Microsofts C++ compiler and related tools does not have the same features as GNUs. They seems to assume that Visual Studio is used on top, which makes them difficult to run on a automated build server. It will in any case require yet another build system that must be maintained in parallel.

DrSuperGood

So why is it failing to build on the server? I know it is because "Shlobj.h" is not available on the build server however is that because it is not a standard header file (available in Windows SDK yet not in other SDKs for building on Windows such as that used by the server) or is it just because of the server needs a configuration update (someone has to add that header to it)?

QuoteThey seems to assume that Visual Studio is used on top, which makes them difficult to run on a automated build server. It will in any case require yet another build system that must be maintained in parallel.
They use some mega complicated cooperate targeted build server system. This most certainly is not a viable solution to the problem. It would be nice if we could work out something to let the nightly server build for Windows without having to sacrifice functionality.

Ters

Quote from: DrSuperGood on September 05, 2014, 02:50:09 PM
I know it is because "Shlobj.h" is not available on the build server however is that because it is not a standard header file

shlobj.h is an ancient, and very central, header file. It probably dates back to Windows 95. New contents are added now and then, but the stuff Simutrans recently started using dates back to a shell update bundled with Internet Explorer 5. The build server has been updated since then.

One possibility is that there are local changes to Makefile on the build server that blocks the change that activates the necessary parts of shlobj.h

DrSuperGood

Quotethat activates the necessary parts of shlobj.h
The problem is not that parts of the header are missing, but the entire header file is missing. The include statement is throwing the compiler error as it cannot locate the file to include. I do not think any changes to the makefile were made to add support for that file (it should be part of the Windows SDK (official or otherwise) that is used and so be in the include/class path).

I will try mingw out later to see if building with it throws the same error (making sure it does not use the VS Windows SDK).

Ters

shlobj.h is part of mingw, and has been since at least 2011. Probably even way before that, considering how important it's contents is, but I don't have any older archives readily available.

What might be throwing the build server off, is that the build server, unlike most of us building for Windows, is case sensitive.

DrSuperGood

Quoteis case sensitive.
So simply changing the case of the import file might fix it? It would be great if that was the case as it would restore nightly builds back to Windows users.

In my Windows SDK it is known exactly as "ShlObj.h" yet the include is "#   include <Shlobj.h>". I am not sure what it is in mingw but there is a good chance that is not the correct case based on this evidence.

Could a developer try and change that to see if it restores nightly compilation? (if so this should be known as a bug?)

Ters

Mingw consistently has all its headers in lower case. The only thing in upper case is the GL directory. This seems to be a Linux/Unix tradition, where only initialism is in upper case (though not consistently).

TurfIt

Appears case sensitivity was the problem...

DrSuperGood

#9
Ah excellent. Glad this is now fixed.

I hope to eventually see more nightly servers now.

Ters

Quote from: DrSuperGood on September 07, 2014, 03:41:20 AM
I hope to eventually see more nightly servers now.

I don't see why. Or how, since there aren't that many in the community with a server. Even less with the time and experience to set up scheduled cross-compilers for the major platforms. Someone set up a Jenkins CI server a while, but it might only do a Linux build. I don't even know it it's still running.

In addition, I suspect multiple nightly servers will just confuse the users, especially as they might have slightly different dependencies, or even functionality. My own builds are certainly different.

DrSuperGood

QuoteI don't see why. Or how, since there aren't that many in the community with a server. Even less with the time and experience to set up scheduled cross-compilers for the major platforms. Someone set up a Jenkins CI server a while, but it might only do a Linux build. I don't even know it it's still running.

In addition, I suspect multiple nightly servers will just confuse the users, especially as they might have slightly different dependencies, or even functionality. My own builds are certainly different.
I meant multiplayer game servers running nightly. Fifty running one over summer lead to the resolution of at least two bugs, the max in-transit overflow and in-transit logging overflow.