Wesnoth 1.0.3 ?

[alberic89]

Hello,
For why we have only windows package of wesnoth 1.0.3, and no source code ?
https://sourceforge.net/projects/wesnot ... oth-1.0.3/

[Pentarctagon]

Given that's now 16 years ago, I doubt anyone remembers the answer to that. The full history with tags is available via the public git repo however.

[gnombat]

Given that's now 16 years ago, I doubt anyone remembers the answer to that. The full history with tags is available via the public git repo however.

There isn't actually a tag for version 1.0.3, though.

There was a mailing list thread in June 2006 about the Wesnoth 1.0.3 release. It's kind of hard to follow, but it appears that this is what happened:

• Some people wanted version 1.0.3 to be released
• The development team was busy working on version 1.1 (soon to be version 1.2) and didn't want to make another 1.0.x release
• Someone else ended up making the release who wasn't usually involved in making releases (this probably explains why they forgot to do some things like update the version number, create a tag, provide downloads other than the Windows package, etc.)

[alberic89]

Thank you for all your answers.
I'm recompiling old versions of the game and I came across this weirdness, without being able to understand it.
By the way, while compiling version 1.2.8, I came across a bug without the compiler or the internet offering me a solution. Not knowing anything about C++, I ask you:

Spoiler:

Code: Select all

In file included from unit.hpp:21:
image.hpp:95:17: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
   95 |                 const type get_type() const { return val_.type_; };
      |                 ^~~~~
In file included from /usr/include/c++/12/bits/stl_algobase.h:64,
                 from /usr/include/c++/12/string:50,
                 from tstring.hpp:17,
                 from terrain.hpp:17,
                 from map.hpp:23:
/usr/include/c++/12/bits/stl_pair.h: In instantiation of ‘struct std::pair<gamemap::location, unit>’:
unit_map.hpp:52:30:   required from here
/usr/include/c++/12/bits/stl_pair.h:192:11: error: ‘std::pair<_T1, _T2>::second’ has incomplete type
  192 |       _T2 second;                ///< The second member
      |           ^~~~~~

The configure file ran without any problem, and make shows me this error (drowned in mountains of various warnings).
g++ is already the newest version (4:10.2.1-1)
cmake is already the newest version (3.18.4-2+rpt1+rpi1+deb11u1).

[egallager]

Thank you for all your answers.
I'm recompiling old versions of the game and I came across this weirdness, without being able to understand it.
By the way, while compiling version 1.2.8, I came across a bug without the compiler or the internet offering me a solution. Not knowing anything about C++, I ask you:

Spoiler:

Code: Select all

In file included from unit.hpp:21:
image.hpp:95:17: warning: type qualifiers ignored on function return type [-Wignored-qualifiers]
   95 |                 const type get_type() const { return val_.type_; };
      |                 ^~~~~
In file included from /usr/include/c++/12/bits/stl_algobase.h:64,
                 from /usr/include/c++/12/string:50,
                 from tstring.hpp:17,
                 from terrain.hpp:17,
                 from map.hpp:23:
/usr/include/c++/12/bits/stl_pair.h: In instantiation of ‘struct std::pair<gamemap::location, unit>’:
unit_map.hpp:52:30:   required from here
/usr/include/c++/12/bits/stl_pair.h:192:11: error: ‘std::pair<_T1, _T2>::second’ has incomplete type
  192 |       _T2 second;                ///< The second member
      |           ^~~~~~

The configure file ran without any problem, and make shows me this error (drowned in mountains of various warnings).
g++ is already the newest version (4:10.2.1-1)
cmake is already the newest version (3.18.4-2+rpt1+rpi1+deb11u1).

I'm guessing that's probably due to the default C++ standard having changed between when 1.2.8 was released and now; try compiling with whatever version of g++ would have been the current version at the time

[alberic89]

Tanks you egallager
I have downloaded the 4.2.2 version of gcc, and I try to compile soon.

[gnombat]

By the way, while compiling version 1.2.8, I came across a bug without the compiler or the internet offering me a solution. Not knowing anything about C++, I ask you:

If you're compiling old versions, it's usually better to use the latest commit on a branch rather than a tagged version (e.g., use branch 1.2 rather than tag 1.2.8). Branches occasionally get bug fixes after the final release was made (sometimes these are things like fixes for modern compilers).

However, that doesn't actually help with the 1.2 branch (and the 1.4 branch) - they have this compilation issue with modern GCC. I used this patch to get it to compile:

wesnoth-1.2.patch

(2.76 KiB) Downloaded 63 times

EDIT: there is a better patch here, I recommend using that one instead.

[Pentarctagon]

Would you be able to submit that as a PR on github?

[gnombat]

Would you be able to submit that as a PR on github?

It may not be a good idea, it was kind of a quick hack (just moving things from the .hpp file to the .cpp file until it compiles ). I'm not 100% sure it won't cause issues (in particular it is likely to be slower than the original). It would be interesting to see if anyone has a cleaner fix for that.

[Pentarctagon]

Well, mainly I'm just thinking it's unlikely there will be any other fix that someone comes up with. Plus given the much more limited hardware that version had to work on, any performance slowdown from this is unlikely to matter.

[alberic89]

But since we are using much more powerful hardware than in the past, the slowdown should be largely compensated, right?

[Pentarctagon]

Right. Even if this somehow reduced the game's performance by half (highly unlikely), improvements in hardware performance over the last 10+ years would still more than compensate for it.

[gnombat]

It will probably work fine on modern hardware. But there's another possible use case: some users might want to run Wesnoth on an older machine, and they know the machine can't handle Wesnoth 1.16 (or any recent version of Wesnoth), so they might try compiling an old version like 1.2 or 1.4. They probably wouldn't want this patch.

[Pentarctagon]

As long as the commit message is clear about what its purpose is, I'd say that should be fine. Anyone building on vintage hardware can either revert the commit or build from the latest tag for that branch.

[alberic89]

I posted a request for help on a French forum (https://linuxfr.org/forums/programmatio ... nt-1905384), and here is the beginning of the proposed solution:

for the first error

Code: Select all

const type get_type() const { return val_.type_; };

you remove the "const" on the left (the first word of the line) which is useless.
for the second one, you add a

Code: Select all

#include <utility>

at the top of the unit_map.hpp file, at the end of the other "#include"

I will test the solution, and if not try the gnombat patch.

One last quick question. I didn't find any instructions to compile from the gitub repository other than with cmake, which is only usable from 1.6.
I tried these commands found on the internet :

Code: Select all

autoheader && aclocal && libtoolize --ltdl --copy --force && automake --add-missing --copy && autoconf

and then the standard installation that gets stuck at sudo make install with the error :

Spoiler:

Code: Select all

Making install in po
make[1]: Entering directory '/home/pi/wesnoth-1.0/po'
Making install in wesnoth
make[2]: Entering directory '/home/pi/wesnoth-1.0/po/wesnoth'
/bin/sh @MKINSTALLDIRS@ /usr/local/share
/bin/sh: 0: cannot open @MKINSTALLDIRS@: No such file
make[2]: *** [Makefile:314: install-data-yes] Error 2
make[2]: Leaving directory '/home/pi/wesnoth-1.0/po/wesnoth'
make[1]: *** [Makefile:388: install-recursive] Error 1
make[1]: Leaving directory '/home/pi/wesnoth-1.0/po'
make: *** [Makefile:530: install-recursive] Error 1 

You can see the complete installation at https://asciinema.org/a/533725.