adding new source files leads to mysterious linking errors

[Jens Beyer]

trunk compiled fine yesterday after the bzr pull (r6149), compiled the changed files and worked correctly.
However, after make clean it did not compile/link anymore.

This occurs after r6148. The r6147 works perfectly.

gcc4.5.3, Linux 32bit. I didn't change anything to the make toolchain (I believe so, at least ;-) )

Console output (the last few lines:)
Linking CXX executable widelands
Linking CXX executable test_widelands_scripting
[100%] Built target test_widelands_scripting
libwidelands_all.a(editorinteractive.cc.o): In function `~Editor_Set_Port_Space_Tool':
/home/beyerj/widelands/widelands/src/editor/tools/editor_set_port_space_tool.h:41: undefined reference to `vtable for Editor_Set_Port_Space_Tool'
libwidelands_all.a(editorinteractive.cc.o): In function `~Editor_Unset_Port_Space_Tool':
/home/beyerj/widelands/widelands/src/editor/tools/editor_set_port_space_tool.h:31: undefined reference to `vtable for Editor_Unset_Port_Space_Tool'
libwidelands_all.a(editorinteractive.cc.o): In function `Tools':
/home/beyerj/widelands/widelands/src/editor/editorinteractive.h:80: undefined reference to `Editor_Set_Port_Space_Tool::Editor_Set_Port_Space_Tool(Editor_Unset_Port_Space_Tool&)'
/home/beyerj/widelands/widelands/src/editor/editorinteractive.h:80: undefined reference to `Editor_Unset_Port_Space_Tool::Editor_Unset_Port_Space_Tool()'
libwidelands_all.a(widelands_map_loader.cc.o): In function `Widelands::WL_Map_Loader::load_map_complete(Widelands::Editor_Game_Base&, bool)':
/home/beyerj/widelands/widelands/src/map_io/widelands_map_loader.cc:156: undefined reference to `Widelands::Map_Port_Spaces_Data_Packet::Read(FileSystem&, Widelands::Editor_Game_Base&, bool, Widelands::Map_Map_Object_Loader&)'
libwidelands_all.a(widelands_map_loader.cc.o): In function `Map_Port_Spaces_Data_Packet':
/home/beyerj/widelands/widelands/src/map_io/widelands_map_port_spaces_data_packet.h:30: undefined reference to `vtable for Widelands::Map_Port_Spaces_Data_Packet'
libwidelands_all.a(widelands_map_loader.cc.o): In function `~Map_Port_Spaces_Data_Packet':
/home/beyerj/widelands/widelands/src/map_io/widelands_map_port_spaces_data_packet.h:30: undefined reference to `vtable for Widelands::Map_Port_Spaces_Data_Packet'
libwidelands_all.a(editor_tool_menu.cc.o): In function `Editor_Tool_Menu::changed_to()':
/home/beyerj/widelands/widelands/src/editor/ui_menus/editor_tool_menu.cc:145: undefined reference to `Editor_Tool_Set_Port_Space_Callback(Widelands::TCoords<Widelands::FCoords>, void*, int)'
libwidelands_all.a(widelands_map_saver.cc.o): In function `Widelands::Map_Saver::save()':
/home/beyerj/widelands/widelands/src/map_io/widelands_map_saver.cc:87: undefined reference to `Widelands::Map_Port_Spaces_Data_Packet::Write(FileSystem&, Widelands::Editor_Game_Base&, Widelands::Map_Map_Object_Saver&)'
collect2: ld gab 1 als Ende-Status zurück
make[2]: *** [src/widelands] Fehler 1
make[1]: *** [src/CMakeFiles/widelands.dir/all] Fehler 2
make: *** [all] Fehler 2

[Hans Joachim Desserud (hjd)]

I ran into the same problem on my 32 bit Arch system (64-bit Ubuntu was ok). However, after deleting everything in the build directory and running compile.sh from scratch I did not have any problems. (Still I would assume make clean should do this)

Also, the PPA seem to build without any problems https://launchpad.net/~widelands-dev/+archive/widelands-daily/+packages

[Jens Beyer (qcumber-some)]

Thanks, that helped.
Also running the cmake command again helps this cause.

The reason is someone added a few sources files, those are not included in the make run, then the linking fails due to unresolved methods. That's why make clean also doesn't help.

compile.sh users are really in bad luck here.

Maybe we should do something about it. It's not really a bug, more a major inconvenience in some rare cases.

[Hans Joachim Desserud (hjd)]

So _that's_ why update.sh run into problems at random intervals and I have to recompile from scratch again?

Oh, and could you update the title as well to reflect the actual problem?

[Jens Beyer (qcumber-some)]

I think this could well be the reason.

There is no standard way in cmake to handle this situation. Let's see if I can come up with a chek-and-fail which should not take more than a few seconds per make.

[Jens Beyer (qcumber-some)]

The cmake people seem to handle this situation by training their developers...

Other way without training would be using explicit source file names in CMakeLists.txt instead of using globbing.
In this way, if a developer adds a source file, he has to add that file to CMakeLists.txt, too - if not, building will fail for the developer already. The user of compile.sh will get a change in CMakeLists.txt which automatically triggers the rerunning of the cmake command, so this user will not run into problems anymore.
This not-globbing way would be more useful for compile.sh users, less irritating for make users, but more work for developers.

Checking all files for their changes is too resource hungry and takes too much time, it would not work well.

What do you think?

[SirVer (sirver)]

I feel this is a *bug* in cmake and we just have to life with it. Running cmake when building fails always solved the issue for me so far.

[Jens Beyer (qcumber-some)]

Committed rev. 6274 to force a cmake run in update.sh by touching CMakeLists.txt.
This results in a few more seconds running time for update.sh, but nothing else should change normally; except that it will pick up new source files this way and not fail without users of compile.sh/update.sh to have to remove everything.

For the general developer using manual cmake/make commands nothing has changed.

I'm feeling this is the most we can do this way; if this is ok with everyone we could set this to Fix Committed/Build17 ;-)

[Shevonar (shevonar)]

Another advantage of always running cmake is a problem I have with building the windows installer: CMake has to run to generate a proper name with the correct bzr version for the installer. This should also be fixed now.

[SirVer (sirver)]

Sounds a good enough solution. People who are sophisiticated enough to
run cmake with their own configuration will understand that it needs to
be rerun when new source files appeared.

  status fixcommitted

[SirVer (sirver)]

Released in build17-rc1.