Need help building winboard

[Charles Browne]

I need to post this to make sure I am handling the 4.3.15 beta source files correctly.

At first the wengineo.c file had me a little confused as to why it was in the source files. Being new to compiling anything, I am in no position to say "yea do this" and "yea do that" and to know with any certainty that my decision was correct.

After opening it with a text editor, I took the wengineo.c file to be a wengineoutput.c file that maybe was in the process of being worked on and the file was just included in the sources. But I think I should have actually been deleting the wengineoutput.c file and renaming the wengineo.c file to wengineoutput.c and compiling with that.

If the information is correct that the wengineo.c file should be renamed wengineoutput.c and used for compiling, the information would be important to anyone that is compiling the beta source files with the cygwin.mak file, as the make file uses the name wengineoutput.c.


I did rename the wengineo.c file to wengineoutput.c, and it compiled without errors or warnings.

wengineo.c file - modified date: December 13, 2008

wegineoutput.c file - modified date: January 28, 2006

I'm posting this really so that if I am wrong in renaming the file, someone can tell me that I am just flat out wrong.

[H.G.Muller]

You are right. The wengineo.c and wengineoutput.c are strictly equivalent, and one of them should be deleted. wengineo.c was Alessandro's original file. I recently shuffled some code around in there (producing the wengineoutput.c) in order to get a better separation of front-end and back-end code, so that I could use it as a starting point for and xboard source (xengineo.c). Therefor it is better to keep the engineoutput.c. In the future I will take out the back-end code (which they have in common) from each of these, and put it in a separate file engineo.c.

For now it does not matter which one you delete, both are tested and work. The only reason to prefer one over the other is that it is more similar to the xboard version.

[Eric Mullins]

OK, thanks very much. I am kind of done with xboard, and returning to WinBoard now to test if I haven't broken anything. This thread was extremely helpful, and I can use the cygwin makefile now to compile the tree 'as is'. Especialy the need for deleting the config.h in the parent (xboard) directory had me baffled. Apparently there is also a definition of HAVE_RANDOM there, and because zippy.c is including a config.h, but is in the xboard directory, it prefers the xboard config.h over that of the winboard directory. So I kept getting errors for calls to the non-existent 'random' from zippy.c only, despite the fact that HAVE_RANDOM was set to false in the winboard/config.h.

This problem is because of the #include order when you compile backend.c (and zippy, etc.) For WinBoard, you want to include config.h from the winboard directory, but the cygwin make file has it #including from the parent directory--not by intent, but by gcc behavior. The solution is to change INCLUDES (in cygwin.mak) as follows:

Code: Select all

INCLUDES= -I. -I..

-- to --

Code: Select all

INCLUDES= -I. -I.. -I-

-I- is supposedly depreciated. But it still works for me using cygwin or mingw. Also note that config.h is supposed to be for what your system has in the way of libraries, etc. I was working with winboard and cygwin makefiles this morning, and noticed some program specific configuration entries in one of the config.h files. That stuff should go elsewhere because it's program configuration, not system capabilities. I got here because the source wouldn't compile because of the NrW issue discussed earlier in the thread.

I've been working with various compilers (for the 4.2.7 source) and creating better makefiles for them and discovered this issue. Compiling with msvc.mak is a nightmare because of this issue and there is no elegant solution. What I ended up doing was creating a rule for each source file in the XB directory. The rule copies from XB to WB, compiles, and then removes it-- all so the #include directives search in the WB directory first for config.h. What a pain.