[hatari-devel] Makefiles removal?

Eero Tamminen eerot at users.berlios.de
Sun Jun 13 21:15:54 CEST 2010


Hi,

On Sunday 13 June 2010, Thomas Huth wrote:
> > Test stuff is developer-only and contains Linux specific things like
> > running the tests under Valgrind (which is Linux only), so I think
> > it's fine to have a normal GNU Makefile there.
>
> Why did you run valgrind from within the Makefile? Shouldn't this
> rather be a separate shell script?

There's also a script (for testing Hatari & Hatari UI scripting), but
the test program stuff is done in the Makefile because that does building,
dependency handling & error handling automatically, so it's better suited
for that than a shell script.

(I can type "make valgrind" and it automatically builds anything needed
and checks whether latest debugger modifications caused any issues.)

There's no need to have CMake stuff in the tests directory as it just adds
an extra step to testing (running of cmake) and otherwise complicates
things, so I think the Makefile can just be added back there (with some
stuff from the old Makefile.cnf included directly into it).


> > As to Mudflap debugging support, I have no idea how to add support
> > to it to CMake, I need your help there.
>
> Well, don't be so lazy, Eero, just have a try, ... and if you get
> stuck, I still can try to help you there.

My guess is that this needs a new "Mudflap/Pointer debugging" build type for
the Hatari CMakefile, as switching to it requires a full re-compile like
switching from the Release to Debug build type does.

Option for this build type should be enabled only if:
* a new enough GCC version is available (at least 4.x)
* build target is x86 (AFAIK mudflap works currently only for x86)
* libmudflap dev package is installed

How to do above?


Also, I had the documentation on the Mudflap usage in Makefile-default.cnf
(as it was developers only and I couldn't think of a better place), I guess
something similar to this can now be put to the main CMakefile?:
---------------
ifneq ($(MUDFLAP),)
# Run-time checks with GCC "mudflap" etc:
# - stack protection
# - checking of pointer accesses (AFAIK works only on x86)
#
# Before build, install "libmudflap<version>-<gcc-version>-dev"
# package (libmudflap0-4.3-dev in Debian Lenny).
#
# To build, use:
#       make clean; make MUDFLAP=1
#
# To run, use something like (disable sound as it can break things):
#   MUDFLAP_OPTIONS="-viol-gdb" ./hatari --sound off
#
# For more info, see (for now, works properly only for x86 gcc):
#   http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging
#
RUNCHECKS = -fstack-protector-all -fmudflapth #-fmudflapir
LDRUNCHECKS = -fmudflapth -lmudflap
endif
...
# Set flags passed to the compiler (e.g. optimization flags)
CFLAGS := -g $(WARNFLAGS) $(OPTFLAGS) $(RUNCHECKS)
...
LDFLAGS ?= $(LDRUNCHECKS)
-----------------

Or maybe there should be some separate developer readme apart
from the readme.txt for the users?


> > Well, it's a bit unfair to remove & break other's code without a
> > warning. I think I'm entitled to cry "foul".  :-)
>
> This certainly hasn't been without a notice. Well, ok, there wasn't a
> direct warning yesterday, but I think we discussed it clearly on this
> mailing list to keep the old Makefiles for the 1.4 release and to
> remove them afterwards.

I had already promised to maintain the Makefiles and understood that they
would be removed for the next major release, not immediately after this one
(i.e. with current release intervals nearly a one year difference in
schedule or at least with some forewarning). :-/


> You added mudflap support just a couple of 
> weeks ago, so instead of adding it to the old Makefiles, you could have
> also added it directly to the new CMake-files instead.

I added it over two months ago to debug just found bugs in Hatari.  At least
for me, it was much faster to do with Makefiles and it seemed proper because
it wasn't a feature needed by Hatari users (who'd use CMake) and Makefiles
were agreed to be fully supported in v1.4.

(For the things that were useful also for users it has been fairly clear how
to add that stuff also to CMake, so I've done that.)


	- Eero



More information about the hatari-devel mailing list