ASAN is always linked in when not using compile.sh

Rather than killing compile.sh which is a HUGE time saver for me, we should rather fix the CMakeLists.txt to switch off ASAN in release builds per default.

I have already done my best to update https://wl.widelands.org/wiki/Building%20Widelands/#cmake-options, but I am not familiar with the systems on Windows and Mac, so I'm not the person to fix that.

Travis, AppVeyor and debian are already fixed and I did ping Tino, but I didn't think of Mac systems - sorry.

Does the attached branch to what we need?

Yes, it should.

> Am 28.11.2017 um 18:20 schrieb GunChleoc <email address hidden>:
>
> Does the attached branch to what we need?
>
> ** Branch linked: lp:~widelands-dev/widelands/bug-1734843-asan-
> buildsystem
>
> ** Changed in: widelands
> Milestone: None => build20-rc1
>
> ** Changed in: widelands
> Status: New => In Progress
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1734843
>
> Title:
> ASAN is always linked in when not using compile.sh
>
> Status in widelands:
> In Progress
>
> Bug description:
> ./compile.sh has grown to become a meta build system around the meta
> build system that cmake already is.
>
> For example, the default for release builds should be that ASAN is not
> linked in. This is not encoded in the CMakeLists.txt though - this
> logic is encoded in compile.sh. This script was always meant to be a
> convenience tool, but by now it is actually expected that people use
> it, otherwise they will get surprising results.
>
> compile.sh hurts. It hurts windows and mac users as it is not cross
> platform. It hurts packagers (they have fixed workflows for cmake
> projects), nightly builders (suddenly all Mac nightlies ship with ASAN
> enabled, though they are release builds) and experienced cmake users.
> It is an additional layer of logic that can contain bugs.
>
> I think we should kill compile.sh and instead educate the community
> how to build Widelands using cMake directly.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/widelands/+bug/1734843/+subscriptions

compile.sh is also very convenient for me. Especially copying the executables (including wl_map_info for testing map uploads locally) to the base dir is convenient. Of course i can do that by hand... Normally my workflow for trunk is:

bzr pull
./compile.sh

Thats all. For testing other branches i use mostly the switches -w -t (exclude website stuff and translations).

Why does it hurts windows and MAC users? No one has to use the script... Maybe this has to be clarified.

If it is really a pain, we can pull it out and serve it as a standalone script. Linux users can download it from somewhere (github?) and save it in the directory he needs it. The script has to be ignored for bzr then.

Fixed in build20-rc1